[gambit-list] Just so I got it right: ___device_tcp_client_read/write_raw_virt doing *len_done = 0; return ___FIX(___NO_ERR); makes Gambit's IO scheduler select() and reiterate?

Mikael mikael.rcv at gmail.com
Wed Feb 25 05:43:26 EST 2015


Marc,

Not super important at all but part of auditing, just to check that I
understand this correctly:

If a blocking Gambit IO operation (e.g. that would be a
|read-subu8vector|/|write-subu8vector| with a positive |need| value or a
|read-byte|/|write-byte|) is currently being invoked on a TCP port,

and the respective ___device_tcp_client_read_raw_virt
or ___device_tcp_client_write_raw_virt procedure invoked does *len_done =
0; return ___FIX(___NO_ERR); ,

then in response to it doing that, will Gambit's IO scheduler (presuming
there's no constraint from TCP port timeout settings) wait for the socket
to show readability or writability respectively using select() and then
reiterate the procedure?


E.g.,
 * |read-byte| is invoked.
 * The TCP port's read buffer is empty so Gambit invokes
___device_tcp_client_read_raw_virt, and it does *len_done = 0; return
___FIX(___NO_ERR); .
 * In response to that, Gambit does select() for readability (not
writability) on the socket, and after some while there socket is found to
have more data available to be read.
 * In response to that, Gambit re-invokes
___device_tcp_client_read_raw_virt. This time it gives 5 bytes. The first
of those bytes will become the |read-byte| call's result.

Thanks,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20150225/9338660c/attachment.htm>


More information about the Gambit-list mailing list