On Mon, 2005-05-30 at 17:42 +0200, kraehe wrote: > Moin Guru's, > > half way back - i've browsed the gst source again. > > I now think that Socket>>next and ServerSocket>>waitForConnection > had been designed to work with process scheduler, by using the > fileOp: 13 and 14 primitives before filling a buffer or waiting. > Now fileOp: 14 is expected to install a signal handle (/me shivers > about C signals - because C signals are evil) an gst is either > losing a signal, or some other reason is blocking those methods. > > So I really run into a bug and will check older versions, if > the bug disappears. > > > The alternate would be to provide a select() primitive. So > > a MUD server is a single Smalltalk process implementing its > > own scheduler. > > the alternate would still be usefull, because several designs > wrap around the select loop, so I wonder why there is'nt any > fileOp: like PRIM_MULTI_POLL using select and not signals to > poll an array of FileStreams in addition to a FileStreams.
Well I think single process model is very easy to program to. That said, it should be possible to provide that whilst implementing an event loop under the scenes as it were. See twisted in python for instance. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
