[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 18:39:25 +0200

Am Mittwoch, den 05.10.2005, 11:16 -0500 schrieb Peter Keller:
> On Wed, Oct 05, 2005 at 09:29:57AM -0000, Thomas Chust wrote:
> > What should be rather easy though, is to implement such a message passing  
> > system between forked processes, because they always share code segments  
> > -- you wouldn't even have to map code pointers to and from anything,  
> > because they would just be the same.
> Well, how about this. 
> 1. Implement a message passing distributed communication system with scheme.
> 2. Design and implement a distributed interpreter for scheme on top of it.

Again that's basically the idea of !

OK, for the time beeing I had to restrict it to a side effect free
subset of Scheme (like DSSSL).  I needed restartable transactions and I
haven't seen a good way to isolate them all.

But experience shows that this DSSSL-style subset is more than enough to
describe single processing steps.

> Of course, this affects performance since scheme is now being interpreted

My profiling shows that setting up an XSLT (implementation incomplete)
transformation with embedded DSSSL/Scheme scripts (in attribute values
wherever XSLT has XPath expressions) will take 10% while the byzantine
synchronisation needs 90% of the time.  So, while I can hardly think of
more overhead for the interpreter, it still has almost no effect.

So it's better to put more logic into single steps and ignore
performance issues for scripting level.

> With this method, you can work out the problems of continuation
> serialization in the scheme emulator.


>   Or, if you decide to become tied
> to someone's implementation, like say Chicken, the emulator for Chicken
> can simply extend the Chicken dialect to support the distributed features
> you need.

That's why I'm a bit sad.  I restricted myself to R5RS, but eventually
some things are RScheme specific now, while the chicken port waits to be
taken up again.

> Once a new distributed dialect of scheme is finalized, then decisions about
> what can be emulated and what can be natively compiled can be made.



reply via email to

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