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

[Christopher Allan Webber]

William ML Leslie writes:

> On 6 December 2015 at 01:58, Christopher Allan Webber
> <address@hidden> wrote:
>> Amirouche Boubekki writes:
>>> 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.
>
> An aside on concurrency models: being able to do this - pause
> execution of one turn and allow another to run - creates a strictly
> more powerful model, but with very different properties for the
> purposes of analysis and auditing.  It means that any time you call a
> function, you need to ensure that if there are properties that a turn
> must maintain - such as there being a constant amount of money in the
> system, for example - that this property is maintained /before/ the
> call.
>
> This feature is known as 'stale stack frames' in the literature
> (particularly in E circles), and in an ideal async world, we'd never
> need to do this.  There's a really accessible post at
> https://glyph.twistedmatrix.com/2014/02/unyielding.html about what can
> happen as codebases grow in a system with the potential for stale
> stack frames.  I also think
> https://wingolog.org/archives/2012/02/16/unexpected-concurrency is
> good to review when discussing this, even though it's dealing with a
> slightly different cause.
>
> I'm not saying that it's a bad idea to expose it in 8sync, btw.  One
> great thing about Guile is that it gives you options about how you
> want to do concurrency.  But libraries that use this feature (or may
> decide to use it in the future) should come with a large, flashing
> warning - calling these functions may allow other events to run!

You're right that these are challenging problems... there are a number
of ways to mitigate them, like using the actor model, etc (which of
course still doesn't give you a perfect model of concurrency) or build a
purely funcitonal system on top where you *expect* that a function is
only computing based off of the information that came into the system,
or many other approaches.

But I think it is possible, and best, to leave answering this question
out of the low-level part of 8sync's scheduler.  Instead, systems can be
built on top of it, both bundled with 8sync, and outside of it as
separate packages.  I think that's the best approach... I already intend
to build an actor model system on top of 8sync and attempt to experiment
with some other systems too.  I'd like 8sync's core to be generic enough
where multiple approaches can be built *on top* of it.

I think the current path 8sync is going down makes that possible.

Anyway, good things to keep in mind! :)