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.

ciao,Michael
-- 
  mailto:[EMAIL PROTECTED]             UNA:+.? 'CED+2+:::Linux:2.4.29'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM


_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Reply via email to