`scm_std_select ()' call in `fport_wait_for_input ()'

[Ludovic Courtès]

Hi,

Kevin Ryde <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:

>> BTW, do you know what the purpose of `fport_wait_for_input ()' is?
>
> Maybe left from the 1.6 cooperative threads.
>
>> It
>> does nothing for O_NONBLOCK streams and waits for events otherwise.
>> Since, for blocking streams, `read ()' does not return until either EOF
>> is reached or at least one octet was read, `fport_wait_for_input ()'
>> seems redundant.
>
> Ahh, hang on, I wonder if it's a hack to do an "exit guile" while
> blocked within a read(), thus allowing gc to run in other threads.
>
> If that's true then presumably the write side is afflicted too, as
> well as various other potentially blocking operations like
> read-string!/partial and gethost.

In node "Blocking", the manual reads this:

  A thread must not block outside of a libguile function while it is in
  guile mode.  The following functions can be used to temporily leave
  guile mode or to perform some common blocking operations in a
  supported way.

The `scm_std_select ()' call does indeed a "leave guile mode", thereby
allowing GC to run, should input data be currently unavailable.  I guess
that's why it's here.

A alternative way to do this would be to have `fport_wait_for_input ()'
call `read(2)' through `scm_without_guile ()'.  This would make the
intent clearer, and may perform slightly better (removes one syscall
from the I/O path).

What do you think?

Thanks,
Ludovic.