On Monday 07 July 2003 10:39, you wrote: > Hi all, > > According to Zoran, using Tcl_RegisterChannel and Tcl_UnregisterChannel > (both with the NULL interp as argument) doesn't look very good. > On my personal experience, I didn't have any troubles using this command, > but the "close" problem I related few days ago that is not important for me > as I open a socket forever.
Yeah, the most common usage, as in my experience, is to open the server channel, accept the connection and pass the connection to other thread for processing. The problem is, that in Tcl a thread "owns" the channel, regardless of wether it is registered in an interp or not. This behaviour may be questionable and subject to improvement, but it is so and we can't change that now. Perhaps for the 9.0, there should be an overhaul of the channel code to accomodate such application patterns. > > I think, using a "get" and "put" command to gain access to the channel in > only 1 thread at a time can be fine, and I can implement that in my module. > The only problem I see is that if the thread cannot release the channel, > other threads will be locked waiting for the channel.. That can be bad. This is purely under app control, as with other shared resources. Therefore, Jim suggested the timeout option, which is a way to graciously cope with such situations, if they occur. > > I will try to find time to have a look at the thread extension module to > check their code. > You're always welcome to do this. If you have any questions, you can contact me directly, since I'm maintaining this Tcl module. To conclude, I think I will revamp the ns_chan command so it reflects ideas presented in this thread, if nobody objects, that is. 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.
