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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Wednesday, November 04, 2009 3:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets, events, semaphores, etc. 2009/11/4 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project