On Monday 15 September 2003 03:46, you wrote:

>  via forked processes and shared memory.  (How true is this really?)

Very true.

> 
>  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?

I already thought about that. Yes, on the Tcl level. you can't just see
the difference between threads vs. processes. In my latest thread
extension work, I' ve made a small step in this direction by adding
a persistence layer to tsv (aka nsv) so distinct processes can share
data over thread shared arrays, as threads can do (this is still work
in progress, not released yet). Currently I've just made a gdbm persistency
layer, but there is an API in the threading extension, so one can wrap
whatever type he/she likes (sql, shared memory, etc).
 
The advantage of having the same model for forked processes
and threads would be (for the Tcl programmer) significant because
one can operate (use) existing MT-unsafe packages. The entire 
thing would be more robust, memory issues (garbage collection)
would be simplified, etc. etc.
One can even think about the combination of both, processes 
and threads all hidden under one Tcl API. 

What do other people think?

Cheers,
Zoran




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tcl-Threads mailing list
Tcl-Threads@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-threads