Re: [Fwd: Re: [Chicken-users] Question]

[Raffael Cavallaro]

On Jan 10, 2006, at 6:15 AM, Jörg F. Wittenberger wrote:

 It might depend on concern:  If you are behind SMP friendly threads that seems about the only way.  But if all you need is a way to call library which has synchronous  API's without blocking all other Scheme threads, it might more efficient to export some way to call back to Scheme from system threads.

True, but this restricts long running worker threads to non-scheme code (i.e., the libraries with synchronous APIs that you discuss). This seems like a rather heavy restriction given a fairly ubiquitous SMP multicore future.

Let me also mention in this context that this is precisely the solution taken by some commercial lisp implementors - only a single thread can be in the lisp core at one time, but external library calls can each run in their own os thread - and in at least one implementation with which I am familiar it means that you either end up rewriting all the long-running parts of your code in c, or your code maxes out one cpu core while the other(s) sit essentially idle. Note that these commercial lisp implementors are moving toward SMP friendly threading in future releases. I think that spawning whole separate scheme interpreter processes using semaphores and shared memory (or some other IPC mechanism) would be preferable in such cases, especially in machines which might well have 4 cores, 3 of which would otherwise sit largely idle.

regards,

Ralph

Raffael Cavallaro, Ph.D.

address@hidden