Re: [AOLSERVER] Tcl shared channels

2003-07-09 Thread Zoran Vasiljevic
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

2003-07-08 Thread Jean-Fabrice RABAUTE
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

2003-07-07 Thread Jean-Fabrice RABAUTE



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 nameat 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_chanregister myfile]
   ... use $fp as normal ...
   ns_chanunregister 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 sufficien

Re: [AOLSERVER] Tcl shared channels

2003-07-06 Thread Jim Davidson




Hi,

This makes sense although I'd suggest a specific command to create the 
resource with a nameat 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_chanregister myfile]
 ... use $fp as normal ...
 ns_chanunregister 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

2003-07-05 Thread Zoran Vasiljevic
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

2003-07-05 Thread Jim Davidson




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

2003-07-05 Thread Zoran Vasiljevic
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

2003-07-04 Thread Jean-Fabrice RABAUTE
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

2003-07-04 Thread Jean-Fabrice RABAUTE
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

2003-07-02 Thread Zoran Vasiljevic
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

2003-07-02 Thread Jean-Fabrice RABAUTE
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

2003-07-01 Thread Dossy
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.


Re: [AOLSERVER] Tcl shared channels

2003-07-01 Thread Jean-Fabrice RABAUTE
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

2003-07-01 Thread Jean-Fabrice RABAUTE
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.