Moin Mike Anderson, > I'm no guru, but it seems to me that you close the socket and it will > never get re-opened. #waitForConnection just returns if the socket is > closed. That means that your code is in an endless loop creating > MUDClients that terminate immediately because the socket is closed.
this would result either in a "Connection closed by foreign host." message, or prevent further telnet connection. Instead an existing telnet connection hangs (does not read characters) till i kick waitForConnection by opening an additional telnet. > I've not done much with networking, so I can't offer a solution with > certainty, but I notice that the NetClients NetServer/NetSession > implementation doesn't close the socket, so perhaps it is as simple as that. my current guess, is that the TCP namespace is an add on and not an integral part of the gst kernel. Its therefore likely that the process scheduler does not check the server socket, and it even looks that a blocking read from console wont yield a select() on all open file descriptors (including the server socket) to deceide for the next co-process to run. Thats the only explaination I have why i need to type something into transcript/console to kick the the co-process to start working. I fear that NetClients NetServer only works, because a httpd does'nt need much concurency. BTW: if co-processses and sockets are working together: would the limit be 250 users (255-stdio-logfile-savefile) - or does gst cascade select() calls to support more than 250 co-processes waiting on more than 255 open files - or does gst use real posix threads to implement co-processes (so it does'nt need to select the io in process scheduler, because a pthread can just block) ? Bye 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
