[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Announcing 8sync: an asynchronous programming language for Guile

From: Amirouche Boubekki
Subject: Re: Announcing 8sync: an asynchronous programming language for Guile
Date: Sun, 06 Dec 2015 01:40:33 +0100
User-agent: Roundcube Webmail/1.1.2

Le 2015-12-05 15:58, Christopher Allan Webber a écrit :
Amirouche Boubekki writes:

* %8sync

This is the main macro, here is it's definition:

(define-syntax-rule (%8sync async-request)
    (abort-to-prompt (current-agenda-prompt) async-request)))

I'm wondering whether (current-agenda-prompt) is useful.
I think the code will abort to the prompt of the current dynamic
context. So except if there is multiple agenda in the same thread,
it's not useful.

You're right that this is the context in which this becomes useful.  I
might have composed agendas at some point.  I'm not sure.

It's comparable to the way I define blocking procedures in async.scm

(define-public (read/ sock)
   (abort-to-prompt 'loop async-request))))

Right, that means that 'loop is always for "the agenda", and there will
always be one.

where `async-request` is in `async.scm`:

(lambda (cc) (loop-add-reader sock (lambda () (cc (read sock)))))

It's the way `async.scm` does blocking calls (and *only* blocking
calls).  `read/` and its `async-request` is missing catch around
`read` and something like `propagate-%async-exceptions`.

8sync doesn't block though.  Its use of select means you only need to
get information once it's available.

The code you have here will block other code that is available to run
while it's waiting for code.

I wrote "blocking" code in the sens that it is a call that blocks
when the port is not ready. In this case `read` is called
when the port is ready via the lambda registered as callback
with `loop-add-reader` which is called via select only when the port is ready.

It's similar to 8sync code, except there is not later dispatch like
in setup-async-request. Instead it's directly registers in the handler
of call-with-prompt.

The argument of the prompt is:

(lambda (cc) (loop-add-reader sock
               (lambda ()
                 (cc (read sock)))))

Which is called by the handle of call-with-prompt as callback:

    (call-with-prompt 'loop
      (lambda (cc callback) (callback cc)))))

Here cc is the continuation of the prompt handler.

tldr: There is certain number of proc that call each other
      in some order for the better good :)

8sync has two types of async-request:

** run-requests, which implements kind of a *coroutine* behavior.

It pause the execution of the current procedure and schedule
the provided lambda to be run soonish; This doesn't exists in
async.scm. The only thing useful this can do, is break the callstack
to allow deeper recursion.

That's not true. See the problems of "callback hell" people get into in
node.js.  8sync mitigates this.

Yes, but this must be mitigated only for calls that would block without

As for the callback stack, it does get broken that's true... but that's
why 8sync gives you copies of all the stacks that were recursively
called as it walks back through its ~futures upon some exception.

This is nice.

I realize I disagreed with a lot of what you said, but a lot of the
things you challenged are intentional designs in 8sync, not accidents.

I do appreciate the feedback though, it helped me clarify some of the
design decisions in 8sync, which will be useful for docs-writing!

Thanks for taking the time to respond it helps better understand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]