Well as the one responsible for the initial vm implementation, let me say: (a) There is fall over code for one semaphore versus three because the windows rewrite took a couple of years to complete, obviously some legacy code could disappear? I doubt anyone has tested the Socket smalltalk code against a 10 year old VM for example, so someone could drop the test and primitive method, etc. (b) The concept came about, via pacing on my boathouse deck and talking to John Maloney at the time was to have three semaphores, one for read, one for write, and one for control. The is/was a state diagram that showed how the three semaphores get signalled depending on the state of the read/write & control (open, closed, accept) transition based on unix BSD socket logic. The VM for unix/linux/os-x based machines technically polls the state of the file descriptors at least on the order of 1 to 3 ms and if the image isn't busy will sleep until the next known wakeup time to service a Delay or if a pending UI event or socket signal occurs.. I'd hunt in the squeak mailing list archives for it. (c) I think I wrote 2 Socket implementations, then it's evolved into what you have today. One of the challenges facing the implementer up in the smalltalk layer is to decide, when: a) Will a listen result in an accept? b) When can I write to a Socket? c) When is the Socket write completed? d) When can I read from a Socket? e) Is there more to read from a Socket? f) If I close a socket, when will the other party close there side? g) When the other party closes the socket when do I know that? In many of the cases waiting forever isn't a choice the developer wants to make, improper choices are subtle issues. For example you open a socket, write 64k of data, close the socket. How long do you wait? Oh yes on a dialup connection running at 32,000 baud why that wait time is much longer than in the lab with 10mb ethernet everywhere... Can I wait forever? Well no since we do at some point want to cleanup and let the other party deal with whatever happened. Can the socket change state between the point we get the first state change and then attempt to service it? Well of course... I believe the listen loop polling is there to deal with issues on some *cough* platforms where the socket might be busted because the listen/ accept handshake might not complete correctly and the socket goes weird, so the timeout/reset dance cleans up the mess, but no-one really determined what the issue was and likely it was platform version dependent anyway. I do recall some effort to implement some complicated schemes where pending queued connection requests could be queued up in the VM to work around problems with mechanics at the BSD socket level with the listen/accept protocols. Also see Craig's work on Flow On 2009-11-04, at 11:35 AM, Schwab,Wilhelm K wrote:
Hello all,
Am I falling into a bad area of the image, or does Pharo poll for socket connections? As an example, look at ConnectionQueue>>getConnectionOrNil. Even the Socket waiting methods are all time-bombed. I would expect these methods to wait on a semaphore signalled by the vm on a socket event. It is one thing to offer time-bombed options, but I see nothing event driven at present :( Am I missing something?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================