Re: [AOLSERVER] Tcl shared channels

[Jim Davidson]

Hi,   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.   -Jim       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 (thread::attach). 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. 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.