Hi Tomas, > I don't think alarm is good enough though. It is good for timeouts > but not for schedulling.
True. I would not use if for scheduling, though, but to terminate operations which might possibly take too long (e.g. 'connect' to another server). > BTW: I found a typo in http://www.software-lab.de/refD.html#alarm > which should be http://www.software-lab.de/refA.html#alarm Thanks! I fixed it in the testing release. > > Not necessarily. If we use the select() mechanism provided by '*Run' > > and 'task', you can make input operations like 'listen', 'accept', > > 'read', 'rd' etc. non-blocking. > > How would this work, could you provide a "simple" example? I posted some examples in my initial response to Konrad yesterday (Message-ID: <[EMAIL PROTECTED]>). For a single port, this could be (task (port 4444) # Listen on port 4444 (when (accept @) # A connect arrived (task @ # Install another task on this socket Sock @ # Keep the socket in the task's env (in Sock # Data arrived on that socket (if (rd) # read them (out Sock (eval @)) # Do something with the data (task Sock) # else we got EOF (close Sock) ) ) ) ) ) # and close the connection This mechanism allows an arbitrary number of connections on port 4444. I have this mechanism very often for communication between different systems. For communication with a browser you would better use (line) instead of (rd), and send HTML-data instead of (eval @). > How would I know that 'read' does not have data available, or only > part of the data is available? For the above communication between my own machines, I can guarantee that no message received with the (rd) is longer than the system pipe buffer size (at least 4096 bytes, larger on most systems). In that case the (rd) will never block if select() said that data are available. If you receive data from a browser, they may be larger. But I think this will never make problems if you always read reasonable chunks (e.g. chunked transfers, or character by character to be absolutely sure) in a single step in the 'task' body. select() will either return immediately when more data are available, or will not call the 'task' body, so nothing will actually block. > If I just use alarm (or maybe > something with smaller granularity) I would be wasting precious time > on timeouts. Yes. So alarm is always just an additional security measure. Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
