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