Re: [AOLSERVER] Tcl shared channels
On Wednesday 09 July 2003 21:14, you wrote: > > Ehm, not only that... There is an inherent problem (non MT-related) > > in Tcl channel handling code with: > > > > Tcl_OpenFileChannel(interp, fileName, mode, permissions) > > > > This function trashes memory when feeded with NULL interp. > > According to its manpage, the interp is optional and can be > > given as NULL if one needs no fancy error reporting if the call > > fails. But, if actually used this way, it brings problems. > > I haven't seen that reported on SF. If it isn't there, please add it. I'm sorry for not doing this promptly. I was very busy last couple of days, so I missed that, but I'm going to add it to SF today. Still havent found why this happens. Purify is silent about that so I have to re-step everything using debugger, which takes some time. Cheer's 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.
Re: [AOLSERVER] Tcl shared channels
> Ehm, not only that... There is an inherent problem (non MT-related) > in Tcl channel handling code with: > > Tcl_OpenFileChannel(interp, fileName, mode, permissions) > > This function trashes memory when feeded with NULL interp. > According to its manpage, the interp is optional and can be > given as NULL if one needs no fancy error reporting if the call > fails. But, if actually used this way, it brings problems. I haven't seen that reported on SF. If it isn't there, please add it. Jeff -- 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.
Re: [AOLSERVER] Tcl shared channels
On Tuesday 08 July 2003 22:36, you wrote: > So, if shared channels are a "hack", that is not thread-safe, and maybe > create crashes, what is the future of the "ns_chan" command ? > If nobody objects, the ns_chan will be rewritten to look like: ns_chan (create, get, put, list, cleanup) as Jim suggested. Channels are *not* going to be shared but instead tossed between interp/threads. Each thread which does a "get" will gain the ownership of the channel until it releases it with "put". Channels are going to be parked in virtual-server-wide table filled in initialy with "create" subcommand. Channles in the parked table can be listed with "list" and the entire table can be cleaned up with "clean". That's a short summary of the discussion we had here. The "share" behaviour, that is, one underlying OS file handle (or socket) shared between two distinct channels from two separate threads is thus *not* possible. This requires some more work and is not that straightforward (if at all) as it appears on the first glance. Therefore, be very careful what you're doing if you'd like to implement this behaviour yourself. > If "ns_chan" will be part of the AS4.0 release, we can warn developers this > is an "experimental" command. Not necessarily, if implemented as stated above. > > So 2 solutions : > > 1/ Keep AS4.0 secure and stable : drop ns_chan command, and allow > developpers who need it to use a module "at their own risk". > 2/ put "ns_chan" into the AS4.0 release and remind developers that this > feature may crash the server... > > What's the AOLserver core team opinion on this subject ? Mine you already have. Depends on what other would say. SInce we have no formal procedures (yet) on how to accept or reject proposals, I'd say (based on the experience) that if nobody objects explicitly, the thing is going to happen. Provided, of course, that somebody will step out and make the actual implementation. In this case, I'll volunteer for this since I've done a similar thing for the Tcl threading extension already. 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.
Re: [AOLSERVER] Tcl shared channels
So, if shared channels are a "hack", that is not thread-safe, and maybe create crashes, what is the future of the "ns_chan" command ? As I need a shared channel feature for a client's site, if the ns_chan command is dropped from the AS4.0 release, I will make the command available from a module (.. by releasing nssharechannel 2.0 module). If "ns_chan" will be part of the AS4.0 release, we can warn developers this is an "experimental" command. So 2 solutions : 1/ Keep AS4.0 secure and stable : drop ns_chan command, and allow developpers who need it to use a module "at their own risk". 2/ put "ns_chan" into the AS4.0 release and remind developers that this feature may crash the server... What's the AOLserver core team opinion on this subject ? Best Regards Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Zoran Vasiljevic Envoyé : mardi 8 juillet 2003 17:44 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On Monday 07 July 2003 10:39, you wrote: > 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. Ehm, not only that... There is an inherent problem (non MT-related) in Tcl channel handling code with: Tcl_OpenFileChannel(interp, fileName, mode, permissions) This function trashes memory when feeded with NULL interp. According to its manpage, the interp is optional and can be given as NULL if one needs no fancy error reporting if the call fails. But, if actually used this way, it brings problems. I'm not sure if AOLserver is using this call this way. I have to go thru code and find out. I'll also have to find out why is this happening. It so subtle, that even Purify can't pinpoint any problems (very strange indeed). It seems that there are more surprises in the channel handling code than I expected 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.
Re: [AOLSERVER] Tcl shared channels
On Monday 07 July 2003 10:39, you wrote: > 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. Ehm, not only that... There is an inherent problem (non MT-related) in Tcl channel handling code with: Tcl_OpenFileChannel(interp, fileName, mode, permissions) This function trashes memory when feeded with NULL interp. According to its manpage, the interp is optional and can be given as NULL if one needs no fancy error reporting if the call fails. But, if actually used this way, it brings problems. I'm not sure if AOLserver is using this call this way. I have to go thru code and find out. I'll also have to find out why is this happening. It so subtle, that even Purify can't pinpoint any problems (very strange indeed). It seems that there are more surprises in the channel handling code than I expected 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.
Re: [AOLSERVER] Tcl shared channels
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.
Re: [AOLSERVER] Tcl shared channels
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 RABAUTECore Services - Enjoy the future todayhttp://www.core-services.frMob: +33 (0)6 13 82 67 67
-Message d'origine-De : AOLserver
Discussion [mailto:[EMAIL PROTECTED]De la part de Jim
DavidsonEnvoyé : dimanche 6 juillet 2003
20:28À : [EMAIL PROTECTED]Objet : Re:
[AOLSERVER] Tcl shared channels
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 pathMost of the time, the pattern of
accessing Tcl channels from several threadsis so that one thread creates
the channel and then passes it to some otherthread for further
operation. Very seldom, one actually needs to access thesame channel
from two or more threads simultaneously. This is pretty trickyto do,
considering all operations (filevents) user can apply to a channelusing
Tcl API.So, if this is true, then, the easiest thread-safe solution
would be to simplydrop the "ns_chan share" command
entirely.Following scenario is thus possible (and
available).Thread A creates the channel by "open", "socket" or any
other Tcland/or AOLserver command. It may operate on the channel, read
fromit, write to it, register callbacks using "fileevent" and
such...At some point, thread A may "ns_chan unregister" the
channelputing 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
channelany more.Thread B can "ns_chan register" the channel,
effectively removing thechannel from the table and registering it in its
current interp, thusgaining ownership of the channel. When done with it,
thread B cansimply close the channel or do "ns_chan unregister" to place
it backin 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 receiveone optional argument which would select
either the thread-private listof registered channels or thread-shared
table of parked channels.I'm not sure how the syntax would look like,
but one can do somethinglike "ns_chan list -shared" or "ns_chan cleanup
-shared" or similar.W/o the "-shared" option, operation would be applied
on threadprivate tables. With the "-shared" option, operation would be
applied onthread-shared tables.That's basically it.I
would like to hear some opinions on this, from the people who wouldlike
to us
Re: [AOLSERVER] Tcl shared channels
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 pathMost of the time, the pattern
of accessing Tcl channels from several threadsis so that one thread
creates the channel and then passes it to some otherthread for further
operation. Very seldom, one actually needs to access thesame channel from two or
more threads simultaneously. This is pretty trickyto do, considering all
operations (filevents) user can apply to a channelusing Tcl API.So,
if this is true, then, the easiest thread-safe solution would be to
simplydrop the "ns_chan share" command entirely.Following scenario is thus
possible (and available).Thread A creates the channel by "open",
"socket" or any other Tcland/or AOLserver command. It may operate on the channel,
read fromit, write to it, register callbacks using "fileevent" and
such...At some point, thread A may "ns_chan unregister" the channelputing 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 channelany more.Thread B can "ns_chan
register" the channel, effectively removing thechannel from the table and
registering it in its current interp, thusgaining ownership of the
channel. When done with it, thread B cansimply close the channel or do "ns_chan
unregister" to place it backin 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 receiveone optional argument which would
select either the thread-private listof registered channels or
thread-shared table of parked channels.I'm not sure how the syntax would look like,
but one can do somethinglike "ns_chan list -shared" or "ns_chan cleanup
-shared" or similar.W/o the "-shared" option, operation would be applied on
threadprivate tables. With the "-shared" option, operation would be
applied onthread-shared tables.That's basically it.I would like
to hear some opinions on this, from the people who wouldlike to use
"ns_chan" functionality. Again, my experience is that thedescribed 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 thebody 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.
Re: [AOLSERVER] Tcl shared channels
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.
Re: [AOLSERVER] Tcl shared channels
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 channelswhich were "shared" this way. Heh.I might want to consult Andreas (Kupries) which has very goodbackground on Tcl channel implementation, but as far as I cantell, the Tcl channels are thread-bound and should not be simplyshared between threads.What one can do is to unsplice the channel from the currentthread/interp, park it into some shared table and then splice it inagain in some other thread/interp. This way, the ownership of thechannel gets transfered in a safe way. There are provisions inTcl lib for this in form of Tcl_SpliceChannel and Tcl_CutChannelcalls. That is, starting from Tcl 8.4.How these can (should) be used, you can see from the current Tclthread 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-acrobaticsbetween threads. Which means that both, yours and AOLserver 4.0implementation, are inherently unsafe and can (will) lead to memorycorruption and other problems.The thing I havent look into is the option of getting the underlyingchannel device (opaque handle) and wrapping a new Tcl channelarround 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) hackssince 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 forsome ideas. In the meantime I will have to look how we can fixAOLserver "ns_chan" command to behave properly. But I'm afraidthat a channel share, i.e. two/more threads operating on the samechannel 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.
Re: [AOLSERVER] Tcl shared channels
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.
Re: [AOLSERVER] Tcl shared channels
Do not hesitate to contact me if I can help. Regards. Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Zoran Vasiljevic Envoyé : vendredi 4 juillet 2003 12:35 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On Friday 04 July 2003 12:00, you wrote: > Hi Zoran, > > I checked the "ns_chan" implementation. > I found that you can share a TCL channel across interps and threads (the > channel is registered in the NULL interp), but you cannot unregister the > channel from the NULL interp. There is no option on the ns_chan command to > do that. > > So, what I understand is that the shared channel will be opened forever.. > Am I wrong saying that ? > If I am right, so trying to unregister the channel form the NULL interp > crashes TCL. That is the bug I actually have in my module. > > 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. 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.
Re: [AOLSERVER] Tcl shared channels
On Friday 04 July 2003 12:00, you wrote: > Hi Zoran, > > I checked the "ns_chan" implementation. > I found that you can share a TCL channel across interps and threads (the > channel is registered in the NULL interp), but you cannot unregister the > channel from the NULL interp. There is no option on the ns_chan command to > do that. > > So, what I understand is that the shared channel will be opened forever.. > Am I wrong saying that ? > If I am right, so trying to unregister the channel form the NULL interp > crashes TCL. That is the bug I actually have in my module. > > 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. 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.
Re: [AOLSERVER] Tcl shared channels
Hi Zoran, I checked the "ns_chan" implementation. I found that you can share a TCL channel across interps and threads (the channel is registered in the NULL interp), but you cannot unregister the channel from the NULL interp. There is no option on the ns_chan command to do that. So, what I understand is that the shared channel will be opened forever.. Am I wrong saying that ? If I am right, so trying to unregister the channel form the NULL interp crashes TCL. That is the bug I actually have in my module. Regards. Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Zoran Vasiljevic Envoyé : mercredi 2 juillet 2003 09:53 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On Tuesday 01 July 2003 23:26, you wrote: > My system is Solaris 2.6, AOLServer 4.0 beta 5 and TCL 8.4.2. > > I will try to clean the code and put it on my web site as v2.0 of my module > this week, so you can have a look. > > But if it's an existing feature of the 4.0 fine ! if so, what is the > function to share channels ? lexxsrv:nscp 1> ns_chan wrong # args: should be "ns_chan command ?args?" lexxsrv:nscp 2> ns_chan sdfgs bad option "sdfgs": must be cleanup, list, share, register, or unregister HTH, 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.
Re: [AOLSERVER] Tcl shared channels
Thank you for the tip ! I will change my code to test and use this new AS4.0 command. I think I will stop my module development as it is redundant with this new command. Best Regards. Jean-Fabrice RABAUTE Core Services http://www.core-services.fr [EMAIL PROTECTED] Mob: +33 (0)6 13 82 67 67 En réponse à Zoran Vasiljevic <[EMAIL PROTECTED]>: > On Tuesday 01 July 2003 23:26, you wrote: > > My system is Solaris 2.6, AOLServer 4.0 beta 5 and TCL 8.4.2. > > > > I will try to clean the code and put it on my web site as v2.0 of my > module > > this week, so you can have a look. > > > > But if it's an existing feature of the 4.0 fine ! if so, what is the > > function to share channels ? > > lexxsrv:nscp 1> ns_chan > wrong # args: should be "ns_chan command ?args?" > > lexxsrv:nscp 2> ns_chan sdfgs > bad option "sdfgs": must be cleanup, list, share, register, or > unregister > > HTH, > 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.
Re: [AOLSERVER] Tcl shared channels
On Tuesday 01 July 2003 23:26, you wrote: > My system is Solaris 2.6, AOLServer 4.0 beta 5 and TCL 8.4.2. > > I will try to clean the code and put it on my web site as v2.0 of my module > this week, so you can have a look. > > But if it's an existing feature of the 4.0 fine ! if so, what is the > function to share channels ? lexxsrv:nscp 1> ns_chan wrong # args: should be "ns_chan command ?args?" lexxsrv:nscp 2> ns_chan sdfgs bad option "sdfgs": must be cleanup, list, share, register, or unregister HTH, 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.
Re: [AOLSERVER] Tcl shared channels
Sorry solaris 2.7 not 2.6 !!! I apologize for the error... Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Jean-Fabrice RABAUTE Envoyé : mardi 1 juillet 2003 23:27 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels My system is Solaris 2.6, AOLServer 4.0 beta 5 and TCL 8.4.2. I will try to clean the code and put it on my web site as v2.0 of my module this week, so you can have a look. But if it's an existing feature of the 4.0 fine ! if so, what is the function to share channels ? Thanks. Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Zoran Vasiljevic Envoyé : mardi 1 juillet 2003 23:08 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On Tuesday 01 July 2003 22:37, you wrote: > Hi all, > > I would like to have a kind of "validation" for my problem. > I am working on the v2.0 version of my nssharechannel. > > Before TCL 8.4 there was a bug that crashed TCL Interp when channel was > unregistered from the NULL interp. > > Now, it's working on one case, but not the other : Can you tell me which system we're talking about? Unix (Linux/Solaris,Darwin) or the Win? Also, exactly which version of Tcl and AOLserver? Can you provide your code for review? I'm asking this because I have already implemented the channel-passing between threads in the Tcl threading extension and it works fine there (except for Win systems where Tcl still has a problem). I'm not sure, but I think AOLserver 4.0 also has this feature (where did I saw that?) 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.
Re: [AOLSERVER] Tcl shared channels
My system is Solaris 2.6, AOLServer 4.0 beta 5 and TCL 8.4.2. I will try to clean the code and put it on my web site as v2.0 of my module this week, so you can have a look. But if it's an existing feature of the 4.0 fine ! if so, what is the function to share channels ? Thanks. Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Zoran Vasiljevic Envoyé : mardi 1 juillet 2003 23:08 À : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On Tuesday 01 July 2003 22:37, you wrote: > Hi all, > > I would like to have a kind of "validation" for my problem. > I am working on the v2.0 version of my nssharechannel. > > Before TCL 8.4 there was a bug that crashed TCL Interp when channel was > unregistered from the NULL interp. > > Now, it's working on one case, but not the other : Can you tell me which system we're talking about? Unix (Linux/Solaris,Darwin) or the Win? Also, exactly which version of Tcl and AOLserver? Can you provide your code for review? I'm asking this because I have already implemented the channel-passing between threads in the Tcl threading extension and it works fine there (except for Win systems where Tcl still has a problem). I'm not sure, but I think AOLserver 4.0 also has this feature (where did I saw that?) 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.
Re: [AOLSERVER] Tcl shared channels
On Tuesday 01 July 2003 22:37, you wrote: > Hi all, > > I would like to have a kind of "validation" for my problem. > I am working on the v2.0 version of my nssharechannel. > > Before TCL 8.4 there was a bug that crashed TCL Interp when channel was > unregistered from the NULL interp. > > Now, it's working on one case, but not the other : Can you tell me which system we're talking about? Unix (Linux/Solaris,Darwin) or the Win? Also, exactly which version of Tcl and AOLserver? Can you provide your code for review? I'm asking this because I have already implemented the channel-passing between threads in the Tcl threading extension and it works fine there (except for Win systems where Tcl still has a problem). I'm not sure, but I think AOLserver 4.0 also has this feature (where did I saw that?) 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.
Re: [AOLSERVER] Tcl shared channels
You're right, min and maxthread are not the same, I will change that, restart server and let you know. Thanks for the tip. Regards. Jean-Fabrice RABAUTE Core Services - Enjoy the future today http://www.core-services.fr Mob: +33 (0)6 13 82 67 67 -Message d'origine- De : AOLserver Discussion [mailto:[EMAIL PROTECTED] la part de Dossy Envoye : mardi 1 juillet 2003 22:48 A : [EMAIL PROTECTED] Objet : Re: [AOLSERVER] Tcl shared channels On 2003.07.01, Jean-Fabrice RABAUTE <[EMAIL PROTECTED]> wrote: > > For my little experience, I set up few months ago an AOLServer instance to > serve on images, (that is NO TCL at all !, not even filter), and the process > started with 10 Mb of memory and is now 22 Mb of memory. 22Mb is the number > I have since 1 week, so I suppose the process will not grow anymore, but > perhaps it should not grow at all I don't know. Do you have minthreads = maxthreads? Otherwise, as threads start up, the footprint will grow until you hit maxthreads. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- 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.
Re: [AOLSERVER] Tcl shared channels
On 2003.07.01, Jean-Fabrice RABAUTE <[EMAIL PROTECTED]> wrote: > > For my little experience, I set up few months ago an AOLServer instance to > serve on images, (that is NO TCL at all !, not even filter), and the process > started with 10 Mb of memory and is now 22 Mb of memory. 22Mb is the number > I have since 1 week, so I suppose the process will not grow anymore, but > perhaps it should not grow at all I don't know. Do you have minthreads = maxthreads? Otherwise, as threads start up, the footprint will grow until you hit maxthreads. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- 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.
