Hi, Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
