|
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.
Anyway, that's true that my module, and I
think the "ns_chan" command as well, doesn't handle concurrent read/write from
several threads. That may be a problem, but I never had a crash nor any problem
with that on my site.
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.
I will try to find time to have a look at
the thread extension module to check their code.
Best regards.
Jean-Fabrice RABAUTE
Core Services - Enjoy the future today
http://www.core-services.fr
Mob: +33 (0)6 13 82 67 67
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.
--
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.
|
