Hm, my recent Expect thread-safety questions on the AOLserver list
made me think about something else:
There's an old argument that threads are "wrong", they're an ugly
performance hack solution to the problem of high process spawning and
context switching overhead, and the "right" solution would simply be
to fix the OS so that using multiple processes with their separate
address space, etc. are fast. AKA, fast processes plus explicit
shared memory ("processes") is a better, cleaner solution than threads
with implicit shared memory ("threads").
I don't really care which argument is "right", but if you think about
it, Tcl's thread design emulates most of the behavior of the
"processes" solution for the Tcl programmer! Each thread has its own
entirely separate interpreter with its own namespaces. Sharing of
data between threads is done solely with explicit nsv (or tsv)
commands. In fact, until you go down beneath the scripting layer and
start writing C code, I suspect that the Tcl programmer likely CAN'T
TELL whether Tcl's threading is in fact implemented via threads, or
via forked processes and shared memory. (How true is this really?)
So, I'm wondering, perhaps it would be useful to add explicit fork and
shared memory support to Tcl, with an API virtually identical to that
of Threads. Has anyone thought about this before? How useful would
it be? What advantages/disadvantages might it have in practice as
compared to using threads?
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
