Re: [Chicken-users] Async IO (was Re: libcurl?)

[F. Wittenberger]

Hi All,

I'm compelled to add my $0.02, even though it's sort of a shameless
plug. www.askemos.org might be interesting to those of you, who are
interested in this thread.

Askemos is a programming environment, which, too, shares the Erlang
style of concurrency.  Persistant objects (basically continuations +
meta data, we call them "places", referencing age old design ideas based
on petri nets) communicate by means of asynchronous, transient and
unreliable messages.

(For the sake of marketing we talk HTTP/S and have an XML representation
of places and messages available.  Those of you, who share my inner
aversion against XML, please recall there's SXML ;-)

Contrary to Erlang or "traditional" languages, threading is *not*
exposed to the user level.  Instead, simillar to the X programming
model, each process (place) proceeds in steps as messages arrive:
http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/AskemosDVM
So programmers basically write a Scheme script, which handles one step.
That's easier to debug than threads.

Please follow the above link when you are interested to read more about
those places beeing in virtual synchrony in a peer-to-peer network
(WAN).  (Sort of simillar to spread.org, just that spread guaranties
delivery order of messages while Askemos provides synchronized state.)
Thus when any one of our currently three machines is missing (e.g., DSL
disconnect), the system continues to work.  Just the isolated one will
become read only.

By means of the above mentioned meta data, Askemos provides some more
guaranties, which are only needed when you target tamper proof
processing and non-repudiation: we track things like type, creator, date
and initial content.  The concept of permission management without
central authority might be most interesting.  (Since no root account ==
no abuse of power.)

The persistancy aspect currently ties the implementation to RScheme.
http://www.rscheme.org/rs/a/2005/persistence/
(Otherwise there has been a chicken port of an older version).
Let me proudly add that the load we've been generating from Askemos has
been pretty helpful to make bugs in the async i/o system and persistant
store of rscheme raise their ugly heads.

For those of you, who want to see it in action before you give it a
closer look please visit
http://www.askemos.org/A5b9f7eeda7f70120b3ad16cb00a26211 to find the
profiler of the running system, timeouts and internal thread listing (I
said: not exposed to user level, the implementation hides them).  Under
"supporting hosts" you'll find links to the other hosts of the
"triumvirat": askemos1 and askemos2.  The latter is behind a cheaper DSL
line, thus sometimes just disconnected.  Please follow the links in the
"public" raw.  The other one wants you to log in (which would give you
some more control buttons to trigger node restart and synchrony checks
etc.)

BTW: we run an uptime counter for the p2p-network here:
http://askemos1.tzv.de/A539cdd39291e7d159c68bb199f5a88d5

best regards

/Jörg

Am Dienstag, den 04.10.2005, 15:44 -0400 schrieb Ed Watkeys:
> Hi,
> 
> Let me go out on a limb and say this: shared global data and
> concurrency go together like water and sodium. Message passing
> approaches have high debuggability and are relatively easy to reason
> about.
> 
> I'm trying to contain my excitement about Termite, because as far as
> I'm concerned it's vaporware until I can grab a tarball and play with
> it. And, while I am a big fan of functional programming, the lack of
> mutation seems like a big price to pay. Oh, and yet _another_ Scheme
> is not a reason to rejoice.