Socket isActive until what or when?

> ... and this means that what we have in VW works, but is a
> not-quite-like-anything-else implementation of sockets which
> introduces all kinds of exciting opportunities to confuse people (e.g.
> me).
>  
I agree with that. That's the Smalltalk-80 design of streams. I think we
could iterate to a new streaming design at some point.

I don't think this is something can have a 'quick fix'..

Mind you, you can call the read:into:startingAt: calls yourself and
catch the EAGAIN exception.. it is Smalltalk code that does the blocking
so you can simply not call that Smalltalk code.

Michael

Michael,

On 20/12/2007, Michael Lucas-Smith <[hidden email]> wrote:

> Mind you, you can call the read:into:startingAt: calls yourself and
> catch the EAGAIN exception.. it is Smalltalk code that does the blocking
> so you can simply not call that Smalltalk code.

Michael, I don't think a direct call to >>read:into:startingAt: would
help me to see the EAGAIN.  This is because the method that does the
primitive socket read (privateReadInto:startingAt:for:) converts the
error number from the primitive call into an OSErrorHolder
needRetrySignal which is caught and restarted (aka retried) in
>>primReadInto:startingAt:for: .  Here is the stack at the instant
where we have the error signal in our hand:

SocketAccessor class(OSErrorHolder class)>>restartableError:
SocketAccessor>>privateReadInto:startingAt:for:
optimized [] in SocketAccessor>>primReadInto:startingAt:for:
BlockClosure>>on:do:
SocketAccessor>>primReadInto:startingAt:for:
SocketAccessor(IOAccessor)>>readInto:startingAt:for:

Also, >>restartableError: gets an EWOULDBLOCK for error code 11 and
not an EAGAIN which fooled me because I had only looked here:

  http://www.phys.ufl.edu/~madorsky/fast/errno.h.html

... but it turns out that EWOULDBLOCK is also error code 11:

  http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html

Doh!  ... but that's just a detail.  The thing is that there is no way
to  trap the EAGAIN without calling private and/or prim methods.  The
SocketAccessor could be (and probably should be) a more transparent
representation of a socket than it is at the moment but perhaps work
on that can wait for the Smalltalk ANSI standard work on sockets to be
done.

Once again, thanks for all the help.  I do have a (rather hacky)
solution that appears to suit my situation for now so this matter is
not a problem right now.

All the best,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/