On Saturday 05 July 2003 17:21, you wrote:
> Hi,
> I wrote the ns_chan code -- not surprised it doesn't work because the
> implementation seemed dubious at the time.

I strongly suggest to follow the following path....

Most of the time, the pattern of accessing Tcl channels from several threads
is so that one thread creates the channel and then passes it to some other
thread for further operation. Very seldom, one actually needs to access the
same channel from two or more threads simultaneously. This is pretty tricky
to do, considering all operations (filevents) user can apply to a channel
using Tcl API.

So, if this is true, then, the easiest thread-safe solution would be to simply
drop the "ns_chan share" command entirely.

Following scenario is thus possible (and available).

Thread A creates the channel by "open", "socket" or any other Tcl
and/or AOLserver command. It may operate on the channel, read from
it, write to it, register callbacks using "fileevent" and such...
At some point, thread A may "ns_chan unregister" the channel
puting it in the thread shared table (which is already in place).
The channel is left in parked state and stays there. After the
"ns_chan unregister", thread A would have no access to the channel
any more.

Thread B can "ns_chan register" the channel, effectively removing the
channel from the table and registering it in its current interp, thus
gaining ownership of the channel. When done with it, thread B can
simply close the channel or do "ns_chan unregister" to place it back
in the shared table, leaving it ready for some other thread to
"ns_chan register" it again.

The "ns_chan cleanup" and "ns_chan list" commands would receive
one optional argument which would select either the thread-private list
of registered channels or thread-shared table of parked channels.
I'm not sure how the syntax would look like, but one can do something
like "ns_chan list -shared" or "ns_chan cleanup -shared" or similar.
W/o the "-shared" option, operation would be applied on thread
private tables. With the "-shared" option, operation would be applied on
thread-shared tables.

That's basically it.

I would like to hear some opinions on this, from the people who would
like to use "ns_chan" functionality. Again, my experience is that the
described functionality is sufficient for most of the usage patterns.
I might be wrong, of course.

Well, any thoughts?


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.

Reply via email to