[squeak-dev] Resuming a SocketStream after a ConnectionClosed exception?

Ben Coman btc at openinworld.com
Tue Feb 14 03:56:12 UTC 2017


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


>
> I really don't know if it is safe to share a socket stream between a reader
> process and a writer process. At a low level (the socket) it should be
> perfectly all right, but I don't know if there is any shared state in the
> SocketStream. In any case, it it's working that's a good sign.
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170214/fea9b8e9/attachment.html>


More information about the Squeak-dev mailing list