Hi Alex,

>> > 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.

select() does not make thinks non-blocking as far as I am aware.  It
just wakes up the process when something is going on.

I think that to be non-blocking, all I/O operations must be able to
say how much data to read/write without blocking.

> I posted some examples in my initial response to Konrad yesterday
>                (if (rd)                   # read them
>                   (out Sock (eval @))     # Do something with the data

I think these two lines are the problematic ones.

> 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 @).

Does not (line) try to read until eol or eof?  That could block if the
client is "naughty" or something happens (like delay while receiving
the line and being in the middle of it).  Also,
http://www.software-lab.de/refL.html#line says

   Note that a single carriage return may not work on network
   connections, because the character look-ahead to distinguish from
   return+linefeed can block the connection.

>> 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.

How can you guarantee that? Simply by sending little data or some
special protocol?

Also, that is a very special case.  I don't think you can make such
assumptions with HTTP server where you don't have the clients under
control.

> 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.

How big is a reasonable chunk?  What if something happens (a delay)
with the client in the middle of sending the chunk?

Would not reading by character loose the magic of striving for
supercalifragilisticexpialidoucious server?;-)


Also, not blocking is only a part of the story, what about
schedulling?  If two people share a computer say with MS-DOS, one must
go for a coffee and wait until the other one finished.  If they use
UNIX, they can work simultaneously because the system splits the time
between them in tiny chunks which they don't notice.  The non-forking
server in picolisp is of the first kind.  Once the server is serving a
request, everything else (all the other requests) have to wait until
it is finished with the current task.

Cheers,

Tomas
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Reply via email to