[Top][All Lists]

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

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

From: F. Wittenberger
Subject: Re: [Chicken-users] Async IO (was Re: libcurl?)
Date: Wed, 05 Oct 2005 11:06:19 +0200

Hi All,

I'm compelled to add my $0.02, even though it's sort of a shameless
plug. 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:
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, 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.
(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 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

BTW: we run an uptime counter for the p2p-network here:

best regards


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.

reply via email to

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