I wrote the ns_chan code -- not surprised it doesn't work because the implementation seemed dubious at the time.
Moving forward, there's some code in tclsock.c which shares channels via dup'ing the underlying socket as Zoran suggested below.  That seems to work but looks like a lot of work.  Otherwise, for sharing an open file/socket we generally write custom commands which do the correct locking and/or ensure atomic I/O operations (using writev, pread, etc.).  Maybe a few good examples of that could be uploaded as modules for others to use.
In a message dated 7/5/2003 6:48:35 AM Eastern Daylight Time, [EMAIL PROTECTED] writes:
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