On Friday 04 July 2003 12:34, you wrote:
> To be honest, I havent look at the implementation yet.
> It seems to me that I should do this soon. I will keep you
> informed about my findings. Thanks for reporting this one.

Well, as it looks like, this sharing of channels looks very suspicious.
No wonder Tcl crashes here/there when unregistering channels
which were "shared" this way. Heh.

I might want to consult Andreas (Kupries) which has very good
background on Tcl channel implementation, but as far as I can
tell, the Tcl channels are thread-bound and should not be simply
shared between threads.

What one can do is to unsplice the channel from the current
thread/interp, park it into some shared table and then splice it in
again in some other thread/interp. This way, the ownership of the
channel gets transfered in a safe way. There are provisions in
Tcl lib for this in form of Tcl_SpliceChannel and Tcl_CutChannel
calls. That is, starting from Tcl 8.4.
How these can (should) be used, you can see from the current Tcl
thread extension (2.5.2 version). Look for the implementation of
"thread::detach", "thread::attach" and "thread::transfer" commands.
Those are used to transfer ownership of a channel between threads
(thread::transfer), park the channel for transfer to some other thread
(thread::detach) and register the parked channel into new thread
This is the only safe way one can handle such channel-acrobatics
between threads. Which means that both, yours and AOLserver 4.0
implementation, are inherently unsafe and can (will) lead to memory
corruption and other problems.

The thing I havent look into is the option of getting the underlying
channel device (opaque handle) and wrapping a new Tcl channel
arround it, effectively getting two channels pointing to same handle.
This is tricky and might have some unwanted side-effects, IMHO.
But, as I said, this I haven't look into seriously. I hate (such) hacks
since they come back to you at the time you don't need them at all.

To make a long story short, consult the Tcl threading extension for
some ideas. In the meantime I will have to look how we can fix
AOLserver "ns_chan" command to behave properly. But I'm afraid
that a channel share, i.e. two/more threads operating on the same
channel will not be possible. At least not with the current Tcl internals.


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