Comments on ‘wip-nio’

Comments on ‘wip-nio’

[Ludovic Courtès]

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?

  • ‘nio’ doesn’t seem very descriptive to me; ‘nbio’ maybe?

  • 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

Re: Comments on ‘wip-nio’

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès <ludo@gnu.org> 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
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3100 bytes --]

Re: Comments on ‘wip-nio’

[Ludovic Courtès]

Hi,

Nala Ginrut <nalaginrut@gmail.com> skribis:

> On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès <ludo@gnu.org> 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.

I’d rather have (ice-9 event) or such, and do our best to provide a
portable implementation of the feature.

[...]

>  • ‘nio’ doesn’t seem very descriptive to me; ‘nbio’ maybe?
>>
>
> In my server project, I named it "aio" since it's asynchronous.

Right, that’s also the name of the POSIX API for that, so it’s probably
a good choice.

Thanks,
Ludo’.

Re: Comments on ‘wip-nio’

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Nala Ginrut <nalaginrut@gmail.com> skribis:
>
>> On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès <ludo@gnu.org> 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.
>
> I’d rather have (ice-9 event) or such, and do our best to provide a
> portable implementation of the feature.

Here's another thought on requirements that might feed into that kind of
support.

I've recently been doing some UI programming, that also 
involves D-Bus.  Now the UI is Enlightenment, so my program's main loop
is the Enlightenment main loop (ecore_main_loop_begin).  But if the UI
used Gtk instead, then obviously the main loop would be gtk_main_loop.

Now consider another module that's mostly dealing with a D-Bus API.
This module has situations where it wants to implement "try calling this
API again in 10 seconds time" (possibly sadly, because it shouldn't have
to poll; but let's say that it does anyway).  How does it do that, while
integrating with the main loop of whatever programs might be using that
module?

It seems like the module has to anticipate the main loop infrastructure
that any using programs will use - which isn't a nice solution.

Having written this, I've realised that in the D-Bus case the module is
actually constrained already, because the concept of being able to
receive a D-Bus signal already implies integration with some kind of
main loop infrastructure.  In my case that's GDBus/GIO/glib, and the
integration with the Enlightenment UI is handled by calling
ecore_main_loop_glib_integrate; but I would guess that there are cases
where a module isn't already constrained like this, and still might want
to use a "do X in N seconds time" function.

Regards,
        Neil

Re: Comments on ‘wip-nio’

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Fri, Mar 23, 2012 at 5:36 AM, Neil Jerram <neil@ossau.homelinux.net>wrote:

> <ludo@gnu.org>but I would guess that there are cases
> where a module isn't already constrained like this, and still might want
> to use a "do X in N seconds time" function.
>
>
>
I think this "do X in N seconds time" function would be useful. And it's
better to provider a "do X in N micro-seconds" too.

[-- Attachment #2: Type: text/html, Size: 737 bytes --]

Re: Comments on ‘wip-nio’

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Besides, I think we need "write bytevector from port and return the
successful size".
Just like "write-string!/partial". Now I have to use utf8->string to
convert the bytevector to string.
Why we need such a thing? Because once we introduced Non-Block IO ,we can
not write the whole bytevector in one time. When we get EAGAIN, we must
skip the bytevector size which is successfully written then try again. So
we need a "write-bytevector!/partial" or something else.
Fortunately, we don't need such a thing for Non-Block reading since we have
call-with-bytevector-output-port which could record the size we received
conveniently.

On Fri, Mar 23, 2012 at 9:17 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

>
>
> On Fri, Mar 23, 2012 at 5:36 AM, Neil Jerram <neil@ossau.homelinux.net>wrote:
>
>>  <ludo@gnu.org>but I would guess that there are cases
>> where a module isn't already constrained like this, and still might want
>> to use a "do X in N seconds time" function.
>>
>>
>>
> I think this "do X in N seconds time" function would be useful. And it's
> better to provider a "do X in N micro-seconds" too.
>
>

[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

Re: Comments on ‘wip-nio’

[Andy Wingo]

On Fri 23 Mar 2012 02:47, Nala Ginrut <nalaginrut@gmail.com> writes:

> Besides, I think we need "write bytevector from port and return the successful size".

That's what (ice-9 nio) from wip-ethreads implements -- the primitives.
It's a little confusing as things have changed some since I first posted
wip-nio.  Summary: have a look at wip-ethreads :)

Andy
-- 
http://wingolog.org/

Re: Comments on ‘wip-nio’

[Andy Wingo]

On Thu 22 Mar 2012 22:36, Neil Jerram <neil@ossau.homelinux.net> writes:

> It seems like the module has to anticipate the main loop infrastructure
> that any using programs will use - which isn't a nice solution.

How about, you write your code in such a way that it deals with eports.
You could surround your code in a prompt that if an eport operation
aborts because it would block, you save the continuation and ask your
main loop to call you again when the port is readable / writable.  When
it calls you again you resume the partial continuation.

If you need to sleep, you use sleep from (ice-9 ethreads).  Somehow we
make it so that ethreads can use other main loops, like the dbus, efl,
etc loops.

Dunno.  So many possibilities!

Andy
-- 
http://wingolog.org/

Re: Comments on ‘wip-nio’

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> On Thu 22 Mar 2012 22:36, Neil Jerram <neil@ossau.homelinux.net> writes:
>
>> It seems like the module has to anticipate the main loop infrastructure
>> that any using programs will use - which isn't a nice solution.
>
> How about, you write your code in such a way that it deals with eports.
> You could surround your code in a prompt that if an eport operation
> aborts because it would block, you save the continuation and ask your
> main loop to call you again when the port is readable / writable.  When
> it calls you again you resume the partial continuation.
>
> If you need to sleep, you use sleep from (ice-9 ethreads).  Somehow we
> make it so that ethreads can use other main loops, like the dbus, efl,
> etc loops.
>
> Dunno.  So many possibilities!

Thanks for the ideas.  I unfortunately have a bit of a cognitive deficit
backlog before I can understand them fully.  I haven't yet understand
prompts properly, and I see that ethreads are built on top of those.
But I'll continue working at it!

         Neil

Re: Comments on ‘wip-nio’

[Andy Wingo]

On Sun 25 Mar 2012 22:17, Neil Jerram <neil@ossau.homelinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> How about, you write your code in such a way that it deals with eports.
>> You could surround your code in a prompt that if an eport operation
>> aborts because it would block, you save the continuation and ask your
>> main loop to call you again when the port is readable / writable.  When
>> it calls you again you resume the partial continuation.
>
> Thanks for the ideas.  I unfortunately have a bit of a cognitive deficit
> backlog before I can understand them fully.  I haven't yet understand
> prompts properly, and I see that ethreads are built on top of those.
> But I'll continue working at it!

Heh, sorry for the brevity!  The problem is that we don't explain them
very well.

Let's consider you have a d-bus callback with fd FD.  You want to do
write some bytes to that FD, then do something else.

You can:

  (define (call/resumable thunk)
    (let ((suspend-tag (make-prompt-tag "suspend")))
      (parameterize ((current-read-waiter
                      (lambda (fd) (abort-to-prompt suspend-tag fd))))
        (call-with-prompt suspend-tag
          thunk
          (lambda (k fd)
            (reschedule! fd (lamdbda () (call/resumable k))))))))

In the case of glib, you would implement reschedule! as some wrapper
that adds fd as a gsource to the current main loop.  When the gsource
fires, you would arrange to call the associated thunk -- in this case a
thunk that calls the captured continuation, within another
call/resumable block.

This assumes you are using (ice-9 eports) from wip-ethreads.  Please
take a look at that code.  It is a ports implementation, written in
Scheme, which uses non-blocking read and write primitives when it needs
to fill / flush its buffers.  If the I/O would block, it calls the
current-read-waiter / current-write-waiter.  Here we parameterize that
waiter to capture the continuation and reschedule.

Let me know if I can muddy^Hclarify things more for you ;-)

Cheers,

Andy
-- 
http://wingolog.org/

Re: Comments on ‘wip-nio’

[Andreas Rottmann]

Nala Ginrut <nalaginrut@gmail.com> writes:

> On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès <ludo@gnu.org> 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.
>
I've been looking a bit at C event loop libraries, and just wanted to
note that libev[0] seems like a viable alternative to libevent.

[0] http://software.schmorp.de/pkg/libev.html

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: Comments on ‘wip-nio’

[Andy Wingo]

Heya :)

On Wed 21 Mar 2012 23:39, ludo@gnu.org (Ludovic Courtès) writes:

> I had a quick look at ‘wip-nio’, and here are initial comments.

Thanks for the feedback!

>   • 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?

It's possible to write a compatibility wrapper.  Note that not all
platforms have poll either; mingw being a notable example.  The reason I
haven't done so yet is that epoll offers a strange interface, I don't
know anything about kqueue yet, and abstraction layers have the
potential to introduce inefficiency.  I'd like to give edge-triggered
epoll a try at some point, for example.  Also the fact that an epoll set
is an fd which itself may be polled allows for nesting schedulers.

In summary, it's not done yet because it's early.  But I have some hopes
that we can produce a portable system, in time.

>   • ‘nio’ doesn’t seem very descriptive to me; ‘nbio’ maybe?

I chose it because of Java's NIO, which introduced non-blocking I/O for
Java.  I'm fine with changing names.

Note that since you reviewed this patch, I split things up a bit more.
(ice-9 nio) holds the nonblocking primitives -- currently read, write,
and accept.  (ice-9 ethreads) builds coroutines on top of that.  I think
I'm going to try to split an (ice-9 eports) out of (ice-9 ethreads)
today.

>   • 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.

I'll look into this.  I've always been meaning to understand FRP, and
the HipHop link looks interesting too.  I'm sure you're right here.

One correction though: you are able to wait for other sources of input.
Consider this definition of `sleep':

    (define (sleep seconds)
      (suspend
       (lambda (ctx thread)
         (add-sleeper! ctx thread seconds))))

For completeness, here's suspend:

    ;; The AFTER-SUSPEND thunk allows the user to suspend the current
    ;; thread, saving its state, and then perform some other nonlocal
    ;; control flow.
    ;;
    (define* (suspend #:optional (after-suspend (lambda (ctx thread) #f)))
      ((abort-to-prompt (econtext-prompt-tag (current-econtext))
                        after-suspend)))

So you see that the procedure passed to suspend gets called from the
dynamic context of the scheduler -- the one that installed the prompt.
Sleeps happen to be handled by the scheduler.  To resume a thread,
because you just got some input, call resume:

    (define* (resume thread thunk #:optional (ctx (ensure-current-econtext)))
      (let* ((cont (ethread-data thread))
             (thunk (lambda () (cont thunk))))
        (schedule-thread! ctx thread thunk)))

This marks the thread as runnable, if it wasn't already.  The thunk that
you pass ends up being invoked in the continuation of the suspend --
check the double-parens above.  In this way you can pass arbitrary
numbers of values, cause exceptions, etc.

The only caveat here is that it doesn't work to resume a thread for a
context that's in an epoll(), because the context won't wake up.  We
need to add a wakeup fd to the epoll, as Haskell's event manager does.

OK, off to hack some more!

Andy
-- 
http://wingolog.org/

Re: Comments on ‘wip-nio’

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Wed 21 Mar 2012 23:39, ludo@gnu.org (Ludovic Courtès) writes:
>
>> I had a quick look at ‘wip-nio’, and here are initial comments.
>
> Thanks for the feedback!
>
>>   • 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?
>
> It's possible to write a compatibility wrapper.  Note that not all
> platforms have poll either; mingw being a notable example.

Yes.  I mean, it would be best if the API were OS-independent, so that
more implementations of it can be added eventually.

Thanks for the rest of the explanations, I’ll jump to the new branch
now.  :-)

Ludo’.