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 at 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 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
>