Sockets, events, semaphores, etc.

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/11/4 Schwab,Wilhelm K <[hidden email]>:
> 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?
>

Network is unreliable, thus you waiting for data/connection during
some time and then abandon this idea.
Without timeouts you would never have the way to interrupt the
connection/data transfer if it takes too long.

> Bill
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sig,

That's what threads and semaphores solve, and far more elegantly that sitting in a wide-open polling loop.  Sounds like this stuff indeed needs to be rewritten.  However, I recall much discussion of one vs. three semaphores, see fail-over code to pick up the single-semaphore (old vm IIRC), etc.  That was a lot of work only to end up polling in the end.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Wednesday, November 04, 2009 3:56 PM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets, events, semaphores, etc.

2009/11/4 Schwab,Wilhelm K <[hidden email]>:
> 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?
>

Network is unreliable, thus you waiting for data/connection during some time and then abandon this idea.
Without timeouts you would never have the way to interrupt the connection/data transfer if it takes too long.

> Bill
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project