Re: non-blocking i/o in guile

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

> Now, how to make this fit with non-blocking I/O?  Initially I thought
> that it would be sufficient to add a kind of sentinel return value that
> would indicate the equivalent of EWOULDBLOCK.  Then we'd have to have
> some interface to get a file descriptor or other waitable (more on this
> later) from the port.  That waitable could be added to a poll set, or we
> could layer blocking I/O on top of nonblocking I/O by calling poll(2) in
> a loop with the read or write.
>
> This would be pretty gnarly but I think it could have worked -- except
> two things: blocking local file access, and Windows.  I explain.
>
> It turns out that even if you set a file descriptor to nonblocking, and
> you use only nonblocking operations on it, if that file descriptor is
> backed by a local file system, operations on it will block.  The FD will
> always poll as readable/writable.  Linux has this problem, and async I/O
> (AIO) doesn't help; glibc implements AIO in user-space with a new thread
> per AIO operation.  Terrible.  FreeBSD does the same but with kernel
> threads, AFAIU.
>
> The upshot is that to reliably do non-blocking I/O over local files you
> need to use thread pools.
>
> I was willing to punt on non-blocking local I/O (and I still am),

I would definitely punt on this.  One could argue that it’s “none of our
business”, in a way.  ;-)

> but then Windows.  Windows doesn't have "poll".

But… Gnulib’s poll module has a Windows implementation.

Would it work to the POSIXy approach you suggest above, use Gnulib, and
enjoy?  :-)

I’m more reluctant to even bother about Windows now that it implements
the Linux syscalls.

WDYT?

Ludo’.