On Wed, Feb 15, 2017 at 8:51 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Feb 14, 2017 at 11:56:12AM +0800, Ben Coman wrote:
On Tue, Feb 14, 2017 at 11:14 AM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Feb 13, 2017 at 06:27:54PM -0800, tim Rowledge wrote:
The good news is that I???ve got the reconnect basically working, at
least from the perspective of the connection getting broken by the mqtt server whilst attempting to read data. I???m not sure right now how I
can
meaningfully test a problem that happens when the write process tries
to
send data.
It is not likely that you will ever encounter an error on write. Once
you
have (or think that you have) a connection established, any small
packet of
data that you write is going to at least make its way out to the
network
regardless of whether anybody at the other end actually receives it.
What you will more likely see instead is a read error because nobody
is at
the other end to talk to you any more, possibly because they did not
like
whatever it was that you last sent to them and decided to close their
end
of the connection, or just because of some kind of network issue.
Given that you are working with small data packets, your writes will
always
appear to succeed immediately without blocking, and you will spend a
lot of
time waiting on blocking reads that will either give you the MQTT
packet
you are looking for, or will fail with an I/O error of some kind.
All in all I???m not at all sure that having two forked processes
working with the same socket stream is the best way to do this but it
seems
to work tolerably for now. Might it be better to have the socket
reading
process at a higher priority? I can???t think of a way to merge the
two,
which might be a better technique.
If you have to ask if raising priority is a good idea, then it isn't
;-)
Why?
Hi Ben,
I meant that comment with a smiley.
I saw that. I just had the wrong smiley interpreter. :) :) Thanks for the expansion. cheers -ben
I was just saying is that adjusting
priorities to address performance is the kind of thing that can cause more problems than it fixes (and often does). So a good rule of thumb is don't do it without a good reason. The case that Tim is describing might be an example of this, because changing process priority would likely have been of no benefit, but could have added risk of other kinds of issues.
Dave
My general impression is that its easier/safer to manage multi-threading
at
the application level where you can see exactly what is going on, than at the system level if that is not *guaranteed* to be thread safe.
You could copy the pattern used by Delay>>schedule:, Delay>>unschedule:, Delay-class>>handleTimerEvent:
cheers -ben