You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_tcl-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2002/11/25 20:27:13 UTC
threads?
Hi, I was browsing around the sources, and I don't see anything
related to threads. Have you given any consideration to making
mod_tcl work on windows and threaded MPM's on Unix?
It might be good to put something in the docs stating where mod_tcl
does and does not work, in the meantime.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by "David N. Welton" <da...@dedasys.com>.
Michael Link <ml...@synthemesc.com> writes:
[ Been away for Thanksgiving... hope you had a good one too. ]
> Apache's threading models already do the work for us. It creates a
> pool of threads to use (similar again to perchild method, just
> threads instead of processes). So all that would need to be done is
> to create an interpreter for each thread, and it will automatically
> be pseudo-pooled for us.
Ok, but what about the shared resources, and interpreter creation
time? I mean, for a normal mod_tcl (or Rivet) you can have it so that
the interpreter that the page is getting is ready to go with all the
goodies loaded and byte-compiled. Losing that would suck.
> If the interpreters are pooled and the threads are pooled, that's a
> lot of pools and potentially another bottleneck. If there are 20
> threads and only 5 interpreters and the site gets slammed by 20
> clients then 15 clients have to wait an unknown amount of time,
> maybe dependent on the keepalive setting also?
More than anything, I suppose this is just kind of ugly and confusing,
so the simplest thing would be to keep it to one interpreter per
thread, and try and keep the number of threads low.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by Michael Link <ml...@synthemesc.com>.
On Tuesday, November 26, 2002, at 02:22 AM, David N. Welton wrote:
>
> Maybe start with 1 per thread, and, if it seems like a good idea, add
> some configurability so that users can control it.
>
>> Now I think that having 1 interp per thread would lose one of the
>> nice features of having multiple threads per process. That is that
>> the threads could share data of some sort of persistent type (cache
>> or whatever strange construct someone thinks of). The solution to
>> this would be to implement Tcl's pushing of scripts onto the event
>> queue of other interpreters in the mod_tcl API. It would be
>> necessary to keep track of the thread/interpreter IDs of all threads
>> and write a procedure to push a script to another interpreter
>> (anything else?).
>
> Well, there is some stuff in the thread script-level package for
> shared resources: 'tsv'.
>
> This has some interesting ideas:
>
> http://www.aolserver.com/docs/intro/tcl2k/html/sld031.htm
>
> I guess the pool of pre-existing interpreters is nice because you
> avoid the startup time.
>
Apache's threading models already do the work for us. It creates a pool
of threads to use (similar again to perchild method, just threads
instead of processes). So all that would need to be done is to create
an interpreter for each thread, and it will automatically be
pseudo-pooled for us. If each interpreter uses 3MB memory (that's 2x
more overhead than my interpreters on Solaris use.) and someone allows
50 idle threads, that's only 150MB of used memory, less if the site is
really boring and most of the httpds are swap'd out. 50 idle threads is
considerable, probably something a large site would do, I think the
default is 5.
If the interpreters are pooled and the threads are pooled, that's a lot
of pools and potentially another bottleneck. If there are 20 threads
and only 5 interpreters and the site gets slammed by 20 clients then 15
clients have to wait an unknown amount of time, maybe dependent on the
keepalive setting also?
It appears that at one time the mpm_beos module did have a threaded
model that created a thread per client, but I don't think it's being
used anymore (creating a new thread per client would be expensive also,
especially if you're /.), the documentation has disappeared and it's
not listed with the other mpm's anymore...
-- Michael K Link
(http://synthemesc.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by "David N. Welton" <da...@dedasys.com>.
Michael Link <ml...@synthemesc.com> writes:
> OK, I understand. I suppose if you had multiple threads using 1
> interpreter it would bottle neck eventually for whatever the
> interpreter might be keeping track of anyways.
Yeah.
> I would expect that it would be possible to create 1 interpreter per
> thread, which would be synonymous with the per child model (each
> process of course has its own interpreter).
That's potentially a lot of interpreters. I think AOLserver uses a
pool, and that's probably not a bad idea. We'll have to think about
it some though, as that ads some complexity.
> I'm not sure if Apache has an "initialization" hook for thread
> initializations, or if the standard "init" hook is called for each
> thread creation, I'll have to research that.
>From what I gathered talking to people at ApacheCon, ChildInit is not
called per thread. It seems as if there is no per-thread init hook,
yet. I guess perl ties interpreters to threads like Tcl, so mod_perl
might have some ideas...
> If it's possible to create 1 interpreter per thread then it wouldn't
> be difficult to keep track which interpreter was needed at request
> time, I think a hash map of the thread id would be sufficient
> located in a global per process memory space, or some sort of shared
> memory.
I *think* apr may provide something, but I'm going out on a limb.
> On Monday, November 25, 2002, at 06:56 PM, David N. Welton wrote:
>
> > Well, it is "thread safe", but individual interpreters can't be
> > called by more than one thread.
> >
> > An important constraint of the Tcl threads implementation is
> > that only the thread that created a Tcl interpreter can use
> > that interpreter. In other words, multiple threads can not
> > access the same Tcl interpreter. (However, as was the case in
> > previous releases, a single thread can safely create and use
> > multiple interpreters.)
> >
> > Which means that if you create one Tcl interpreter, and then a bunch
> > of threads, you are in a bad spot.
> >
> > The problem is how to associate a request handler, which is being
> > called in its own thread, with one and only one Tcl interpreter.
> > Either that, or, I guess, create some kind of global mutex on the
> > interpreter, so that it only gets hit by one request at a time, but
> > that seems really ugly and slow.
>
> It is ugly and would be slow, especially for concurrent highly used
> systems. Or even systems with multiple processors, it would be very
> inefficient.
Yep.
> Having 1 interp per thread seems reasonable and relatively
> simple. The only problem is that it needs more memory, but I think
> most people would spare more memory for speed?
Maybe start with 1 per thread, and, if it seems like a good idea, add
some configurability so that users can control it.
> Now I think that having 1 interp per thread would lose one of the
> nice features of having multiple threads per process. That is that
> the threads could share data of some sort of persistent type (cache
> or whatever strange construct someone thinks of). The solution to
> this would be to implement Tcl's pushing of scripts onto the event
> queue of other interpreters in the mod_tcl API. It would be
> necessary to keep track of the thread/interpreter IDs of all threads
> and write a procedure to push a script to another interpreter
> (anything else?).
Well, there is some stuff in the thread script-level package for
shared resources: 'tsv'.
This has some interesting ideas:
http://www.aolserver.com/docs/intro/tcl2k/html/sld031.htm
I guess the pool of pre-existing interpreters is nice because you
avoid the startup time.
> I was reading the threading model at this location:
> <http://www.tcl.tk/doc/howto/thread_model.html>, It was dated March
> 8, 2002, I'm not sure if anything has changed for 8.4 since that was
> written (8.4 was still alpha/beta then right?).
I'm sure that it's acurate.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by Michael Link <ml...@synthemesc.com>.
OK, I understand. I suppose if you had multiple threads using 1
interpreter it would bottle neck eventually for whatever the
interpreter might be keeping track of anyways. I would expect that it
would be possible to create 1 interpreter per thread, which would be
synonymous with the per child model (each process of course has its own
interpreter). I'm not sure if Apache has an "initialization" hook for
thread initializations, or if the standard "init" hook is called for
each thread creation, I'll have to research that. If it's possible to
create 1 interpreter per thread then it wouldn't be difficult to keep
track which interpreter was needed at request time, I think a hash map
of the thread id would be sufficient located in a global per process
memory space, or some sort of shared memory.
On Monday, November 25, 2002, at 06:56 PM, David N. Welton wrote:
> Well, it is "thread safe", but individual interpreters can't be called
> by more than one thread.
>
> An important constraint of the Tcl threads implementation is
> that only the thread that created a Tcl interpreter can use
> that interpreter. In other words, multiple threads can not
> access the same Tcl interpreter. (However, as was the case in
> previous releases, a single thread can safely create and use
> multiple interpreters.)
>
> Which means that if you create one Tcl interpreter, and then a bunch
> of threads, you are in a bad spot.
>
> The problem is how to associate a request handler, which is being
> called in its own thread, with one and only one Tcl interpreter.
> Either that, or, I guess, create some kind of global mutex on the
> interpreter, so that it only gets hit by one request at a time, but
> that seems really ugly and slow.
It is ugly and would be slow, especially for concurrent highly used
systems. Or even systems with multiple processors, it would be very
inefficient.
Having 1 interp per thread seems reasonable and relatively simple. The
only problem is that it needs more memory, but I think most people
would spare more memory for speed?
Now I think that having 1 interp per thread would lose one of the nice
features of having multiple threads per process. That is that the
threads could share data of some sort of persistent type (cache or
whatever strange construct someone thinks of). The solution to this
would be to implement Tcl's pushing of scripts onto the event queue of
other interpreters in the mod_tcl API. It would be necessary to keep
track of the thread/interpreter IDs of all threads and write a
procedure to push a script to another interpreter (anything else?).
I was reading the threading model at this location:
<http://www.tcl.tk/doc/howto/thread_model.html>, It was dated March 8,
2002, I'm not sure if anything has changed for 8.4 since that was
written (8.4 was still alpha/beta then right?).
>
> Threads make my head hurt:-)
>
-- Michael K Link
(http://synthemesc.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by "David N. Welton" <da...@dedasys.com>.
Michael Link <ml...@synthemesc.com> writes:
> Actually, it's possible to compile the library to be thread safe,
Well, it is "thread safe", but individual interpreters can't be called
by more than one thread.
An important constraint of the Tcl threads implementation is
that only the thread that created a Tcl interpreter can use
that interpreter. In other words, multiple threads can not
access the same Tcl interpreter. (However, as was the case in
previous releases, a single thread can safely create and use
multiple interpreters.)
Which means that if you create one Tcl interpreter, and then a bunch
of threads, you are in a bad spot.
> but it had problems in 8.3, I think 8.4 may have fixed a lot of
> these issues. The problem is more complicated by the fact that if
> the library is compiled that way it's possible to have separate
> threads created in the script, I don't think it will matter much,
> but I haven't tested it yet. I don't think having an array of
> interpreters would be the best solution, if anything it is probably
> possible to make 1 interpreter as usual and use Tcl's threading
> functions to deal with it all. Looking at the man pages there exists
> a bunch of threading functions for the interpreter:
> ...
> ie. Tcl_CreateThread(...) would be used to make a new thread and
> there is probably a way to detach it let it run out with the request
> handler, or maybe join if necessary.
The problem is how to associate a request handler, which is being
called in its own thread, with one and only one Tcl interpreter.
Either that, or, I guess, create some kind of global mutex on the
interpreter, so that it only gets hit by one request at a time, but
that seems really ugly and slow.
> I hope that makes sense.
Threads make my head hurt:-)
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by Michael Link <ml...@synthemesc.com>.
Actually, it's possible to compile the library to be thread safe, but
it had problems in 8.3, I think 8.4 may have fixed a lot of these
issues. The problem is more complicated by the fact that if the library
is compiled that way it's possible to have separate threads created in
the script, I don't think it will matter much, but I haven't tested it
yet. I don't think having an array of interpreters would be the best
solution, if anything it is probably possible to make 1 interpreter as
usual and use Tcl's threading functions to deal with it all. Looking at
the man pages there exists a bunch of threading functions for the
interpreter:
void
Tcl_ConditionNotify(condPtr)
void
Tcl_ConditionWait(condPtr, mutexPtr, timePtr)
void
Tcl_ConditionFinalize(condPtr)
Void *
Tcl_GetThreadData(keyPtr, size)
void
Tcl_MutexLock(mutexPtr)
void
Tcl_MutexUnlock(mutexPtr)
void
Tcl_MutexFinalize(mutexPtr)
int
Tcl_CreateThread(idPtr, threadProc, clientData, stackSize, flags)
int
Tcl_JoinThread(id, result)
ie. Tcl_CreateThread(...) would be used to make a new thread and there
is probably a way to detach it let it run out with the request handler,
or maybe join if necessary.
I hope that makes sense.
I did get on the list OK. Thanks.
On Monday, November 25, 2002, at 06:11 PM, David N. Welton wrote:
> Michael Link <ml...@synthemesc.com> writes:
>
>> Yes, in fact I had a version with 8.3 running in threading mode but
>> it was horribly unstable. GDB wasn't much help at the time as it
>> reported very strange results, I've been meaning to run some tests
>> again with updated development software.
>
> Well... the problem would be that Tcl's interpreters are not thread
> safe - you have to have one per thread, no?
>
> After chatting a bit with some of the httpd guys at ApacheCon, the
> thing that comes to mind would be a thread of Tcl interpreters that
> are called up, and locked for the duration of their use within a
> thread. Sounds hairy, though:-/
>
> BTW, did you get subscribed to this list ok?
>
> --
> David N. Welton
> Consulting: http://www.dedasys.com/
> Personal: http://www.dedasys.com/davidw/
> Free Software: http://www.dedasys.com/freesoftware/
> Apache Tcl: http://tcl.apache.org/
>
-- Michael K Link
(http://synthemesc.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by "David N. Welton" <da...@dedasys.com>.
Michael Link <ml...@synthemesc.com> writes:
> Yes, in fact I had a version with 8.3 running in threading mode but
> it was horribly unstable. GDB wasn't much help at the time as it
> reported very strange results, I've been meaning to run some tests
> again with updated development software.
Well... the problem would be that Tcl's interpreters are not thread
safe - you have to have one per thread, no?
After chatting a bit with some of the httpd guys at ApacheCon, the
thing that comes to mind would be a thread of Tcl interpreters that
are called up, and locked for the duration of their use within a
thread. Sounds hairy, though:-/
BTW, did you get subscribed to this list ok?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org
Re: threads?
Posted by Michael Link <ml...@synthemesc.com>.
Yes, in fact I had a version with 8.3 running in threading mode but it
was horribly unstable. GDB wasn't much help at the time as it reported
very strange results, I've been meaning to run some tests again with
updated development software.
On Monday, November 25, 2002, at 01:27 PM, David N. Welton wrote:
>
> Hi, I was browsing around the sources, and I don't see anything
> related to threads. Have you given any consideration to making
> mod_tcl work on windows and threaded MPM's on Unix?
>
> It might be good to put something in the docs stating where mod_tcl
> does and does not work, in the meantime.
>
> --
> David N. Welton
> Consulting: http://www.dedasys.com/
> Personal: http://www.dedasys.com/davidw/
> Free Software: http://www.dedasys.com/freesoftware/
> Apache Tcl: http://tcl.apache.org/
>
-- Michael K Link
(http://synthemesc.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: mod_tcl-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: mod_tcl-dev-help@tcl.apache.org