(Hi Ian, thanks for grabbing this issue by the... well, something! ;-) I
hope you don't mind me crossposting this to the list)

I got the following from Ian (after I forwarded the latest exchange from
John McIntosh etc to him). Great Things Are Afoot! :-)

regards, Göran

PS. I am watching! I mean, we can't allow Andreas to have the VM which
handles Sockets "best", right? :-) DS

Ian Piumarta <ian.piumarta at inria.fr> wrote:
> Goran,
> 
> Thanks for forwarding this stuff.
> 
> > Since I know you are not on the squeak-dev list
> 
> I actually am on the list (twice, for some bizarre reason, with two
> different [but equivalent] email addresses ).  My mail filter siphons
> squeak-dev traffic off into a separate inbox, but I only read it in
> "spare cycles" -- which are sometimes lacking.
> 
> > I think you should be
> > aware of the fact that there have been about 10 posts from Andreas, Lex
> > and John McIntosh on the Socket thread.
> 
> I know: it's asking _so_ much of people to keep me on the cc: list for
> discussions like this...
> 
> Maybe if we had two lists (as was suggested several times in the last
> half decade) to keep image/application development mail completely
> separate from VM development stuff, I'd happily let the latter get
> through to my main inbox.
> 
> > And then there is a new thread called "Re: Will the real sqUnixSocket.c
> > step forward?"
> 
> Sounds like a challenge. ;-)
> 
> I think the real problem is that AIO was invented when we only had one
> semaphore per socket, whereas now we have three.  AIO has trouble
> keeping connect/close, read and write completely distinct from each
> other -- hence the confusion between the use of AIO_RW[X] as a "catch
> all" and the use of AIO_RD and AIO_WR separately.  (The problem is
> *not* really in the signaling logic, but rather in the "suspend" logic
> to turn off notification once something "interesting" has happened.
> It's here that we've too little information to do The Right Thing in
> all situations.)
> 
> Here's what I'll do: today (if it turns out to be straightforward) or
> this weekend (if it turns into a brain-teaser) I'm going to rethink
> and reimplement the whole of AIO (and by implication its interface/use
> in sockets, X11, RFB, etc.) to address the Big Issue.  In which
> case...
> 
> > Subject: Re: Will the real sqUnixSocket.c step forward?
> 
> will probably turn into "will the real socket.c, aio.c, X11.c, etc.c,
> please step forward".
> 
> One thing John has correctly identified (and which I didn't realise,
> nor even suspect) is that the connection semaphore has to be signaled
> on listen and bind (which in Unix is kind of redundant, since these
> operations are synchronous).
> 
> FWIW...
> 
> > aioEnable(12) socket 12
> > data available (no)
> > aioHandle(12, dataHandler,7) set_fd socket 12 for read/write/exceptions
> > aioSuspend(12)  suspend socket 12? <<<<-----***
> > dataHandler(12,0xXXXXXXX,4) callback for socket 12
> 
> the "***" is completely correct: it's the order of the printfs in the
> code that is confusing.  (The suspend is the first action performed by
> the data handler.  The reason it comes before the printf of
> "dataHandler" is total archaeology: back in the days when SIGIO was
> still used it was important to disable SIGIO for the socket before
> attempting _any_ other IO, including IO to std{in,out,err}.)
> 
> Watch this space!  I'm going to go and make a pot of really strong
> coffee, then sit down and fix this mess once and for all (with a
> sledgehammer if necessary ;).
> 
> Regards,
> 
> Ian