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.


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