On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès
<address@hidden> wrote:
Hello,
I had a quick look at ‘wip-nio’, and here are initial comments.
• epoll is Linux-specific. Any idea how a more multi-platform API
could be provided? I guess libevent could be used, but we don’t
want to add one more dependency in 2.0. How much is (ice-9 nio)
dependent on epoll vs. poll, for instance?
Maybe add a module named "(ice-9 linux)"? And we may add more Linux-specific things.
Also "(ice-9 bsd)" which provides "kqueue" or other interesting things.
If users try to use BSD-specific modules under Linux, we may throw an exception. And functions like
"under-bsd?" or "under-linux?" maybe helpful.
Anyway, libevent for Guile is also a good idea. But I don't think libevent should integrate into Guile. We can write
a standalone guile-libevent.
• ‘nio’ doesn’t seem very descriptive to me; ‘nbio’ maybe?
In my server project, I named it "aio" since it's asynchronous.
• I agree that it’s an important problem to address, and I like the
use of coroutines, and I like that it actually solves the problem
for some applications like the web server.
However, I think the approach has shortcomings: (1) it doesn’t
accept other sources of events (timers, mouse clicks, etc.), and
(2) it doesn’t allow you to do something while waiting (of course,
other threads/waiters get scheduled, but the caller is just
waiting, so you can’t for instance update your progress bar while
waiting for your bytevector to arrive.)
Functional reactive programming à la FrTime [0], and synchronous
reactive programming à la HipHop [1] seem to be much more generic
and expressive. It would be great if Guile would come with such a
framework eventually. It’s probably more work, though, so it
probably makes sense to have an alternative mechanism in the
meantime.
WDYT?
Thanks,
Ludo’.
[0] http://www.cs.brown.edu/~greg/
[1] http://www-sop.inria.fr/members/Gerard.Berry/Papers/plastic2.pdf