Re: [AOLSERVER] Tcl shared channels

[Jim Davidson]

Hi,   This makes sense although I'd suggest a specific command to create the resource with a name at startup.  The use would then be similar to nsdb handles:   at startup:     set fp [open /my/file]     ns_chan create myfile $fp   in a thread:     set fp [ns_chan register myfile]     ... use $fp as normal ...     ns_chan unregister myfile $fp     You might want to use the subcommands "get" and "put" instead of "register" and "unregister" to clarify the thread is getting exclusive access to the resource.  Also, timeout support could be convienent, e.g.:   if ![ns_chan register myfile 200 fp] {  ... handle timeout after 200ms ... } ... use channel set in $fp ...     Finally, consider the deadlock detection code in nsdb as well although that may be going to far -- a note in the docs to always get channels in the same order should suffice.   -Jim           In a message dated 7/5/2003 2:11:31 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: On Saturday 05 July 2003 17:21, you wrote: > Hi, > > I wrote the ns_chan code -- not surprised it doesn't work because the > implementation seemed dubious at the time. I strongly suggest to follow the following path.... Most of the time, the pattern of accessing Tcl channels from several threads is so that one thread creates the channel and then passes it to some other thread for further operation. Very seldom, one actually needs to access the same channel from two or more threads simultaneously. This is pretty tricky to do, considering all operations (filevents) user can apply to a channel using Tcl API. So, if this is true, then, the easiest thread-safe solution would be to simply drop the "ns_chan share" command entirely. Following scenario is thus possible (and available). Thread A creates the channel by "open", "socket" or any other Tcl and/or AOLserver command. It may operate on the channel, read from it, write to it, register callbacks using "fileevent" and such... At some point, thread A may "ns_chan unregister" the channel puting it in the thread shared table (which is already in place). The channel is left in parked state and stays there. After the "ns_chan unregister", thread A would have no access to the channel any more. Thread B can "ns_chan register" the channel, effectively removing the channel from the table and registering it in its current interp, thus gaining ownership of the channel. When done with it, thread B can simply close the channel or do "ns_chan unregister" to place it back in the shared table, leaving it ready for some other thread to "ns_chan register" it again. The "ns_chan cleanup" and "ns_chan list" commands would receive one optional argument which would select either the thread-private list of registered channels or thread-shared table of parked channels. I'm not sure how the syntax would look like, but one can do something like "ns_chan list -shared" or "ns_chan cleanup -shared" or similar. W/o the "-shared" option, operation would be applied on thread private tables. With the "-shared" option, operation would be applied on thread-shared tables. That's basically it. I would like to hear some opinions on this, from the people who would like to use "ns_chan" functionality. Again, my experience is that the described functionality is sufficient for most of the usage patterns. I might be wrong, of course. Well, any thoughts? 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. -- 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.