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