On Thu, May 02, 2002 at 12:26:37PM -0700, John M McIntosh wrote:
> >
> >Hopefully John, Ian and Lex can work through the current code and get it
> >working. And then we need to decide what to do with the Unix port at 
> >SF. IMHO we
> >need to have Ian "with us" - let's just find a good "procedure" for this.
> >
> >regards, Göran
> >
> >Göran Hultgren, goran.hultgren at bluefish.se
> >GSM: +46 70 3933950, http://www.bluefish.se
> >\"Department of Redundancy department.\" -- ThinkGeek
> 
> Well the fix exposed a problem with the code.
> 
> Now correct me if I'm wrong, but I don't think CONN_NOTIFY flag is 
> actually set anywhere?

I believe it is set when the server socket is initially created --
that's why Goran's example code, which uses a server socket, manages to
work: you get notification about the *first* connect.  However,
acceptHandler probably does not turn CONN_NOTIFY back on after an
accept() call.  If someone wants to stick a "pss->pendingEvents|= CONN_NOTIFY"
in acceptHandler in the multiListen branch on the SF version, that
would be great!  I won't have time to diddle with it for a week or two.


Alternatively, we could mimick the way READ_NOTIFY and WRITE_NOTIFY 
get turned on: when the image asks if there is a connection available,
then, if there is not, turn on CONN_NOTIFY.  The place to do this would
be socketStatus().  Simply turn on CONN_NOTIFY if state==WaitingForConnect.
Then all the other places CONN_NOTIFY gets turned on could be eliminated.
This is a slight change in how things are done, but it seems simpler
and easier to get right on the whole.


By the way, someone mentioned AIO_RW being used indescriminantly in
dataHandler.  Could you make sure your CVS is up to date?  I thought
I had fixed that, but maybe I overlooked some instances.


-Lex