Do you have a *rationale* for why the existing 1-semaphore primitives
are insufficient?  Certainly the existing primitives are already
implemented on all platforms, they are fast enough to saturate a 10 MBit
network, and they are equally good under multithreaded access.

I'm wondering if it would be worthwhile to just go back to 1-semaphore
primitives, especially since it has the least impact on existing ports.

-Lex



John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> MMm this a complicated subject, there are some others that have interest,
> Lex Spoon, Craig Latta, and Andreas Raab (all of which I've cced). Craig for
> example has a long paper on his site about some ideas on this very topic.
> Also source code etc etc (Ya they all read the list, but some are busy with
> Camp Smalltalk)
> 
> Also remember a support issue is that you must support old images with the
> new VM and C socket code. Therefore you must mimic the behavior of the 2.7 C
> socket code. (Perhaps not the broken behavior)
> 
> 
> > 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
> 
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> Custom Macintosh programming & various Smalltalk dialects
> PGP Key: DSS/Diff/46FC3BE6
> Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
> ===========================================================================