[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?

Marc Feeley feeley at iro.umontreal.ca
Wed Feb 25 07:17:58 EST 2015


Yes, you got it right (if by “positive need” you mean >= 1).

Marc

> On Feb 25, 2015, at 5:43 AM, Mikael <mikael.rcv at gmail.com> wrote:
> 
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4839 bytes
Desc: not available
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20150225/d07b5a79/attachment.bin>


More information about the Gambit-list mailing list