erlang's "process"

[Donn Cave]

Quoth David Garamond <davegaramond at icqmail.com>:
| i watched the LL2 video last night:
|
|   http://ll2.ai.mit.edu/
|
| and found joe armstrong's presentation about the erlang language 
| interesting. i visited the erlang's homepage and browse around for a while.
|
| from what i can see, erlang's approach to parallel programming is with 
| user-level processes, and not os-/user-level threads. the erlang process 
| does not share any data with other processes, and all communication 
| ("user-level IPC") is done with messages. perl's ithreads is somewhat 
| like this too, i believe, in which thread creation will produce a 
| per-thread copy of global variables. unless specifically specified as 
| shared, all global variables are not shared by default.
|
| i'm wondering if python has/will have a similar approach too. one of the 
| frequent traps/complexities of multithread programming is about managing 
| shared access to data. the nothing-is-shared approach is interesting in 
| this regard.

You can certainly do it in Python, maybe not with the elegance you'd
see in Erlang but then you could do it in a native OS-level multithreaded
context, where Erlang can't go.  I've used this approach on BeOS with
its multithreaded user interface API, and I think it's terrific.

I think the main thing you have to deal with is a basic procedural
coding problem.  Often it will be perfectly convenient to toss off
a message and go back to wait for further developments, but there
will be times when the message is relevant to a particular context
defined by the current computation.  I've tried "stackless" Python
out on this, and it worked, very interesting, but that was the old
stackless with the full continuation model - anyway, the point is
that your procedure can be suspended and "continued" on receipt
of the reply.

But the practical requirement is just a thread-interlocked queue, right?

	Donn Cave, donn at drizzle.com