[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-blocking i/o in guile
From: |
Ludovic Courtès |
Subject: |
Re: non-blocking i/o in guile |
Date: |
Thu, 19 May 2016 17:30:32 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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’.