Erlang has a very simple runtime model - processes basically don't have a stack across invocations (message receives) or a dynamic environment, the only concurrency is in mailboxes, and despite claims of being "soft real-time" there's actually not a lot you can do to influence scheduling policy.
Gambit supports pre-emptive multitasking for green threads, with continuations, exceptions, dynamic-wind, and (optionally inheritable) dynamic environments.
Gambit provides mailboxes, but also locks and condition-variables (with a much richer API than most implementations; usually CVs wake either one or all threads, Gambit has functions for both).
Comments
all that it's doing for you is just thinly "papering over" the syscalls
But wasn't that the whole point of Node - to expose the lower layer of nonblockingness while still allowing a high level language for everything else?
If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM
That's interesting. What are the distinctive points that make it good?
Erlang has a very simple runtime model - processes basically don't have a stack across invocations (message receives) or a dynamic environment, the only concurrency is in mailboxes, and despite claims of being "soft real-time" there's actually not a lot you can do to influence scheduling policy.
Gambit supports pre-emptive multitasking for green threads, with continuations, exceptions, dynamic-wind, and (optionally inheritable) dynamic environments.
Gambit provides mailboxes, but also locks and condition-variables (with a much richer API than most implementations; usually CVs wake either one or all threads, Gambit has functions for both).
Gambit also has a pretty good story for controlling thread scheduling and task deadlines (see SRFI-21: http://srfi.schemers.org/srfi-21/srfi-21.html).
The manual describes these things pretty well:
http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Thread...