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, 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
Yes, you got it right (if by “positive need” you mean >= 1). Marc
On Feb 25, 2015, at 5:43 AM, Mikael <mikael.rcv@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
Super thanks. 2015-02-25 17:47 GMT+05:30 Marc Feeley <feeley@iro.umontreal.ca>:
Yes, you got it right (if by "positive need" you mean >= 1).
Marc
On Feb 25, 2015, at 5:43 AM, Mikael <mikael.rcv@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
participants (2)
-
Marc Feeley -
Mikael