John M McIntosh wrote:
> 
> on 7/19/00 8:05 PM, Rob Withers at slosher2 at home.com wrote:
> 
> > Hi All,
> >
> > I am digging into the sqUnixNetwork.c code to try and implement Accepts
> > and so forth.  I am grabbing some stuff from the 2.7 impl and looking at
> > the new Mac impl.  My main design question is what is the benefit of the
> > three semaphore model?
> >
> > I am also trying to implement a backlog queue for listening, and so I am
> > looking at modifying the privateSocketStruct.  Are there still
> > situations where we can miss connections?  How do those happen?
> >
> > Finally, there are a whole slew of error states that these buggers can
> > be in.  Does anyone have a list of those?
> >
> > Any information is very welcome,
> > Rob
> 
> Well I've some background information about why three on my web page
> 
> http://www.smalltalkconsulting.com/html/OTNotes1.html

Thank you, John.  I'm slowly working my way through it and the
conditions which signal the various semaphores.  It is Mac specific as
far as the interfacing into the Mac (no, really?) and the capabilities
it has.  I am learning that Unix has a different model with select and
the implementation of the asynchronous handlers.  I think we will need a
way to differentiate between reads and writes for the dataHandler.  Does
anyone know of a way to do this?

> Also I've some thoughts about programming patterns that could use three
> semaphores. Mostly focused around a read thread, a write thread, and a
> control thread for listen/accept/close/destroy for which I didn't want to
> share a single or two semaphores in some manner between all three threads.

This is hitting on where I am confused.  I've not had communication
theory, formally, but I'd like to take a stab at this, if I may.   My
cloud is about the fundamental communication pattern that Squeak Sockets
are using with the VM, versus the communication model is that
sqUnixNetwork.c uses with the OS (it gets aioPollForIO() calls from
sqXWindows.c, I believe, and then invokes the current registered
handler), and versus how we really want Sockets to behave.  

We want to be really sleeping, with no polling, when there aren't any
events, right?  And we also want to conserve resources and control that
event channel for all subsystems that may be signalled.  So we want an
event that gets put on a queue with some address information and tap a
semaphore.  The interested party can make blocking calls to the
"EventManager" which will sleep on a Semaphore guarding the queue, until
a timeout or a match occurs.  In the case of the socket code, we want to
register addressing callbacks for various events from the network
interface.  The async code in the network plugin can push data to the
eventManager, which will manage all semaphore interaction.  I think this
would clean up the socket code considerably, and we can implement the
current Squeak model using Promises for the wait* methods.  If we can
document a platform-independent state transition specification for
sockets, then we can wrap all platform specific errors in Exceptions,
and event those with the exception address for the Socket.  With all the
wait methods gone, and the semaphore signalling, then we would have only
the control methods (listen, accept, connect, close, shutdown, abort,
readData and writeData)  and the handlers.  Does this make sense?

I've this strange feeling that it is somewhere in Tim's recent post. :)
 
> MMM error codes?, well some errors are thrown from C primitive code based on
> exceptions about incoming parms, or setup issues. These can be the same
> between dialect and of course should be, I doubt they are today. Other error
> codes are specific to the hosting OS since they percolate upwards from the
> OS routines but need to be passed upwards to Squeak so the fellow that is
> trying to understand why the socket connection failed can at least somewhere
> refer to the tcp/ip manual for his hosting OS and get an explanation about
> what he is doing wrong.
> 

So I am just going to try and implement the three semaphore code and see
where that takes me.  I will definitely need to know how to
differentiate between reads and writes if there is a ready answer..

thanks again for the help.  I'll probably blow up my machine tonight,
though!  ;)

cheers,
Rob

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!