unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Amirouche Boubekki <amirouche@hypermove.net>
To: Christopher Allan Webber <cwebber@dustycloud.org>
Cc: guile-devel-bounces+amirouche+dev=hypermove.net@gnu.org,
	guile-devel@gnu.org
Subject: Re: Asynchronous event loop brainstorm at FSF 30
Date: Sun, 04 Oct 2015 15:24:48 +0200	[thread overview]
Message-ID: <6256857ed9f289c87b0deafd17bc8eb9@hypermove.net> (raw)
In-Reply-To: <87k2r3tvzh.fsf@dustycloud.org>

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.



  reply	other threads:[~2015-10-04 13:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-03 22:29 Asynchronous event loop brainstorm at FSF 30 Christopher Allan Webber
2015-10-04 13:24 ` Amirouche Boubekki [this message]
2015-10-04 15:19   ` Christopher Allan Webber
2015-10-04 15:24 ` Christopher Allan Webber
2015-10-04 15:58 ` Nala Ginrut
2015-10-04 16:15 ` Chris Vine
2015-11-17 17:46   ` Christopher Allan Webber
2015-11-18 10:26     ` Chris Vine
2015-11-18 14:37       ` Christopher Allan Webber
2015-11-19 13:27       ` Chris Vine
2015-11-18 12:44 ` Mikael Djurfeldt
2015-11-18 14:16   ` Christopher Allan Webber
2015-11-18 16:36     ` Mikael Djurfeldt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6256857ed9f289c87b0deafd17bc8eb9@hypermove.net \
    --to=amirouche@hypermove.net \
    --cc=cwebber@dustycloud.org \
    --cc=guile-devel-bounces+amirouche+dev=hypermove.net@gnu.org \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).