[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic Courtès
Subject: `scm_std_select ()' call in `fport_wait_for_input ()'
Date: Sun, 13 May 2007 19:13:51 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)


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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]