Re: Asynchronous event loop brainstorm at FSF 30

[Chris Vine]

On Wed, 18 Nov 2015 10:26:25 +
Chris Vine  wrote:
> On Tue, 17 Nov 2015 11:46:24 -0600
> Christopher Allan Webber  wrote:
> [snip]
> > This sounds very interesting... is the source available?  Could you
> > point to it?
> > 
> > Thanks!
> >  - Chris  
> 
> No it's not.  I'll email you something.

In case it's of use to others in looking at the options, I have now put
the code here:
http://www.cvine.plus.com/event-loop/event-loop.scm

I have no problem with any parts of it going into guile if thought
useful.  I was inclined to apply the MIT license to it but that seems
fairly pointless give that guile is covered by the LGPL.  The
interesting part is not so much the event loop but the use of
coroutines to give "await" type semantics. This particular
implementation does allow tasks to run in their own threads in a safe
way.

It works for my limited purposes but I imagine it could be much
improved.

Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Mikael Djurfeldt]

Yes.

I'm sure both you and Mark can judge this better than can, currently.

I just didn't think Guile was that thread-unsafe.  I imagined you
would have to use mutexes around some I/O and common datastructures,
and that that would be about it, but I'm probably wrong...

Best regards,
Mikael

On Wed, Nov 18, 2015 at 3:16 PM, Christopher Allan Webber
 wrote:
> Mikael Djurfeldt writes:
>
>> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
>> cweb...@dustycloud.org>:
>>>  - This would be like asyncio or node.js, asynchronous but *not* OS
>>>thread based (it's too much work to make much of Guile fit around
>>>that for now)
>>
>> Why is this (too much work for threads)?
>
> Threads bring a lot of risky problems.  I really don't want to deal with
> that much locking.  A lot of Guile's code isn't thread-safe... if we
> wanted to go to the "oh yeah super safe with threads!" direction,
> it might require something like Clojure's software transactional
> memory.  I talked to Mark Weaver about this; it's very expensive to do,
> super hard to implement (I don't think we have any guile devs
> interested), and makes things slower whenever you *aren't* using
> threads.
>
> The asyncio / node.js style of things can solve IO bound problems.  As
> for CPU bound, we can use message passing between threads or processes.
>
> It's beneficial to focus on message passing for CPU bound issues anyway,
> because this means that our code will be able to span across machines,
> if said messages are serializable.
>
> Does that make sense?
>  - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Mikael Djurfeldt]

Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
cweb...@dustycloud.org>:
>  - This would be like asyncio or node.js, asynchronous but *not* OS
>thread based (it's too much work to make much of Guile fit around
>that for now)

Why is this (too much work for threads)?

Re: Asynchronous event loop brainstorm at FSF 30

[Chris Vine]

On Tue, 17 Nov 2015 11:46:24 -0600
Christopher Allan Webber  wrote:
[snip]
> This sounds very interesting... is the source available?  Could you
> point to it?
> 
> Thanks!
>  - Chris

No it's not.  I'll email you something.

Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

Mikael Djurfeldt writes:

> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
> cweb...@dustycloud.org>:
>>  - This would be like asyncio or node.js, asynchronous but *not* OS
>>thread based (it's too much work to make much of Guile fit around
>>that for now)
>
> Why is this (too much work for threads)?

Threads bring a lot of risky problems.  I really don't want to deal with
that much locking.  A lot of Guile's code isn't thread-safe... if we
wanted to go to the "oh yeah super safe with threads!" direction,
it might require something like Clojure's software transactional
memory.  I talked to Mark Weaver about this; it's very expensive to do,
super hard to implement (I don't think we have any guile devs
interested), and makes things slower whenever you *aren't* using
threads.

The asyncio / node.js style of things can solve IO bound problems.  As
for CPU bound, we can use message passing between threads or processes.

It's beneficial to focus on message passing for CPU bound issues anyway,
because this means that our code will be able to span across machines,
if said messages are serializable.

Does that make sense?
 - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

Chris Vine writes:

> On Tue, 17 Nov 2015 11:46:24 -0600
> Christopher Allan Webber  wrote:
> [snip]
>> This sounds very interesting... is the source available?  Could you
>> point to it?
>> 
>> Thanks!
>>  - Chris
>
> No it's not.  I'll email you something.
>
> Chris

Thanks!  I'm reading the code you sent me.  Before I had received your
code, I had started on something yesterday... I'm happy to see we have
some similar ideas.  I might borrow some from you.

I'll be posting what I have shortly, as soon as I have enough little
demos locally to prove whether the thing I wrote makes sense or not.

 - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

Chris Vine writes:

> It is certainly the case that mixing threads with coroutines is usually
> best avoided, otherwise it becomes very difficult to know what code
> ends up running in which particular thread and thread safety becomes a
> nightmare.  However, it would be good to allow a worker thread to post
> an event to the event loop safely, whereby the handler for the posted
> event would run in the event loop thread.  asyncio allows this.
>
> Although not particularly pertinent to this proposal, which looks
> great, I use coroutines implemented with guile's delimited
> continuations for a minimalist "await" wrapper over glib's event loop
> as provided by guile-gnome (the whole thing is about 20 lines of code),
> which appears (to the user) to serialize the GUI or other events posted
> to the event loop.  When I don't want to use guile-gnome, which is most
> of the time, I have my own (also minimalist) thread-safe event loop
> using guile's POSIX wrapper for select.
>
> My uses of guile are pretty undemanding so as I say these are
> minimalist.  Something like asyncio for guile would be very nice indeed.
>
> Chris

This sounds very interesting... is the source available?  Could you
point to it?

Thanks!
 - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Amirouche Boubekki]

Héllo,

Please excuse my layman question in advance.

I find the idea awesome to work on asynchronous framework for Guile.

Le 2015-10-04 00:29, Christopher Allan Webber a écrit :

So David Thompson, Mark Weaver, Andrew Engelbrecht and I sat down to
talk over how we might go about an asynchronous event loop in Guile 
that

might be fairly extensible.  Here are some of what we discussed, in
bullet points:

 - General idea is to do something coroutine based.


IUC coroutine takes advantage of the ability to pause the execution of 
given procedure A to run a blocking operation B and execute some other 
procedure C while the blocking operation B is running. At some point, 
when the blocking operation B is finished, and C is finished, A restarts 
where it left.



 - This would be like asyncio or node.js, asynchronous but *not* OS
   thread based (it's too much work to make much of Guile fit around
   that for now)

 - If you really need to maximize your multiple cores, you can do
   multiple processes with message passing anyway


Does it mean that there will be one event loop per thread per process ?



 - So what we really need is a nice API for how to do coroutines, write
   asynchronous code, and work with some event loop with a scheduler




 - Probably a good way to start on this would be to use libuv (or is it
   libev?) and prototype this.  It's not clear if that's a good long
   term approach (eg, I think it doesn't work on the HURD for those who
   care about that, and Guix certainly does)


In asyncio the event loop can be swapped the default event loop is pure 
python. You mean that the first version will use libuv (libuv is the 
nodejs eventloop, formely based on libev).




 - Binary/custom ports could be a nice means of abstraction for this

So, that's our thoughts, maybe someone or one of us or maybe even *you*
will be inspired to start from here?



I don't want to make promises (pun on punpose) but I find this proposal 
really interesting.

Re: Asynchronous event loop brainstorm at FSF 30

[Nala Ginrut]

Hi Christopher!
I'm one of guys who's interested in this topic, say, async IO in Guile.

On Sat, 2015-10-03 at 17:29 -0500, Christopher Allan Webber wrote:
>  - This would be like asyncio or node.js, asynchronous but *not* OS
>thread based (it's too much work to make much of Guile fit around
>that for now)

Personally, I would like to avoid callback way for asyncio which is the
way in node.js. And I believe we have chances to avoid it in Guile.

>  - If you really need to maximize your multiple cores, you can do
>multiple processes with message passing anyway

I've learned roughly about how Erlang deals with multicore problem (I
don't know if Erlang has better solution since 2008). I'm not going to
discuss about the design here, but I have to mention that a proper
general coroutine interface in Guile core should provide a flexible way
to let users do there scheduling policy with multicores. Maybe it's too
idealism, but it's no harm to list it before the coding work.

>  - Initially, this would probably providing a general API for
>coroutines.  Mark thinks delimited continuations would not be as
>efficient as he'd like, but we think it's okay because we could
>provide a nice abstraction where maybe something nicer could be
>swapped out later, so delimited continuations could at least be a
>starting point.

Yes the current delimited-continuations is not so efficient. I think it
has to be optimized in the future. But I'm still standing on optimistic
side of delimited-continuation based asyncio design. Yes, I know it's
faster (in single core) if we use libev/libuv, which keeps fewer
information/states for each request compared to continuations. But I
don't see it's the best solution for scalability taking advantage of
distributed system.

Maybe I'm a little out of topic, a general async event loop is
unnecessary to be salable.

>  - So what we really need is a nice API for how to do coroutines, write
>asynchronous code, and work with some event loop with a scheduler
> 
>  - On top of this, "fancier" high level systems like an actor model or
>something like Sly's functional reactive programming system could be
>done.

Yes, it's better than playing raw continuations, which is hard to handle
and debug. ;-)

>  - Probably a good way to start on this would be to use libuv (or is it
>libev?) and prototype this.  It's not clear if that's a good long
>term approach (eg, I think it doesn't work on the HURD for those who
>care about that, and Guix certainly does)

Anyway, it's no harm to add an implementation based on libuv/libev, but
I think it's improper to be put in Guile core. Or we'll introduce third
party lib as the prerequisites.
Unfortunately, there's no epoll in GNU/Hurd although it is believed not
so hard to be added based on current `select' in Glibc (different from
Linux, these stuffs are in userland on Hurd). I have discussed it with
Hurd folks, but we still have no coding work for it yet.

Again, it's no harm to add it as a lib, folks need efficient asyncio,
always.

>  - Binary/custom ports could be a nice means of abstraction for this

Years ago, Mark Weave has told me (actually it's a kindly warning) that
we have to handle the ports properly for nonblock asyncio. It could be
more complex if one uses DB in her/his program. It's better if we could
have better abstraction for these ports. But I still have no idea about
it.


Any more comments? I think it's better to discuss it more, and list
more potential issues to be noticed。There're always big problems when you
want to design general interface.

Re: Asynchronous event loop brainstorm at FSF 30

[Chris Vine]

On Sat, 03 Oct 2015 17:29:16 -0500
Christopher Allan Webber  wrote:

> So David Thompson, Mark Weaver, Andrew Engelbrecht and I sat down to
> talk over how we might go about an asynchronous event loop in Guile
> that might be fairly extensible.  Here are some of what we discussed,
> in bullet points:
> 
>  - General idea is to do something coroutine based.
> 
>  - This would be like asyncio or node.js, asynchronous but *not* OS
>thread based (it's too much work to make much of Guile fit around
>that for now)
> 
>  - If you really need to maximize your multiple cores, you can do
>multiple processes with message passing anyway
> 
>  - Initially, this would probably providing a general API for
>coroutines.  Mark thinks delimited continuations would not be as
>efficient as he'd like, but we think it's okay because we could
>provide a nice abstraction where maybe something nicer could be
>swapped out later, so delimited continuations could at least be a
>starting point.
> 
>  - So what we really need is a nice API for how to do coroutines,
> write asynchronous code, and work with some event loop with a
> scheduler
> 
>  - On top of this, "fancier" high level systems like an actor model or
>something like Sly's functional reactive programming system could
> be done.
> 
>  - Probably a good way to start on this would be to use libuv (or is
> it libev?) and prototype this.  It's not clear if that's a good long
>term approach (eg, I think it doesn't work on the HURD for those
> who care about that, and Guix certainly does)
> 
>  - Binary/custom ports could be a nice means of abstraction for this
> 
> So, that's our thoughts, maybe someone or one of us or maybe even
> *you* will be inspired to start from here?
> 
> To invoke Ludo, WDYT?
>  - Not Ludo

It is certainly the case that mixing threads with coroutines is usually
best avoided, otherwise it becomes very difficult to know what code
ends up running in which particular thread and thread safety becomes a
nightmare.  However, it would be good to allow a worker thread to post
an event to the event loop safely, whereby the handler for the posted
event would run in the event loop thread.  asyncio allows this.

Although not particularly pertinent to this proposal, which looks
great, I use coroutines implemented with guile's delimited
continuations for a minimalist "await" wrapper over glib's event loop
as provided by guile-gnome (the whole thing is about 20 lines of code),
which appears (to the user) to serialize the GUI or other events posted
to the event loop.  When I don't want to use guile-gnome, which is most
of the time, I have my own (also minimalist) thread-safe event loop
using guile's POSIX wrapper for select.

My uses of guile are pretty undemanding so as I say these are
minimalist.  Something like asyncio for guile would be very nice indeed.

Chris

Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

So David Thompson, Mark Weaver, Andrew Engelbrecht and I sat down to
talk over how we might go about an asynchronous event loop in Guile that
might be fairly extensible.  Here are some of what we discussed, in
bullet points:

 - General idea is to do something coroutine based.

 - This would be like asyncio or node.js, asynchronous but *not* OS
   thread based (it's too much work to make much of Guile fit around
   that for now)

 - If you really need to maximize your multiple cores, you can do
   multiple processes with message passing anyway

 - Initially, this would probably providing a general API for
   coroutines.  Mark thinks delimited continuations would not be as
   efficient as he'd like, but we think it's okay because we could
   provide a nice abstraction where maybe something nicer could be
   swapped out later, so delimited continuations could at least be a
   starting point.

 - So what we really need is a nice API for how to do coroutines, write
   asynchronous code, and work with some event loop with a scheduler

 - On top of this, "fancier" high level systems like an actor model or
   something like Sly's functional reactive programming system could be
   done.

 - Probably a good way to start on this would be to use libuv (or is it
   libev?) and prototype this.  It's not clear if that's a good long
   term approach (eg, I think it doesn't work on the HURD for those who
   care about that, and Guix certainly does)

 - Binary/custom ports could be a nice means of abstraction for this

So, that's our thoughts, maybe someone or one of us or maybe even *you*
will be inspired to start from here?

To invoke Ludo, WDYT?
 - Not Ludo