<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 11:14 AM, 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">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 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.<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 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 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.<br>
><br>
<br>
If you have to ask if raising priority is a good idea, then it isn't  ;-)<br></blockquote><div><br></div><div>Why?    </div><div>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.  </div><div><br></div><div>You could copy the pattern used by Delay>>schedule:, Delay>>unschedule:, Delay-class>>handleTimerEvent:</div><div><br></div><div>cheers -ben</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I really don't know if it is safe to share a socket stream between a reader<br>
process and a writer process. At a low level (the socket) it should be<br>
perfectly all right, but I don't know if there is any shared state in the<br>
SocketStream. In any case, it it's working that's a good sign.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br></div></div>