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

Ben Coman btc at openinworld.com
Wed Feb 15 16:28:16 UTC 2017


On Wed, Feb 15, 2017 at 8:51 PM, David T. Lewis <lewis at 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 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 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
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170216/2e4271f2/attachment.html>


More information about the Squeak-dev mailing list