You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <ma...@unipr.it> on 2011/07/29 19:39:17 UTC
Tcl_Mutex call
Hi guys
I'm reviewing mod_rivet.c to understand what
making it mpm-worker compliant is about. Currently mod_rivet
fails miserably when running with the threaded mpm,
still this is an issue we should try to
deal with.
It seems someone (Damon?) laid down the code
setting up Rivet to support threads by putting the
content generation within a pair of
Tcl_MutexLock-Tcl_MutexUnlock calls.
I don't see any other purpose for this and there is
no comment explaining the need for this. I
This is not enought to let it work and anyway
Rivet should use apr_* call to better suit the Apache
threading model.
Anyone can recall why these calls made it into the code?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Tcl_Mutex call
Posted by Massimo Manghi <ma...@unipr.it>.
Running Apache and Rivet from the debugger might help to grasp what's
going on, but I think I have to read some other module's code in order
to understand.
In principle one has to design a module so that it's mpm agnostic as
much as possible (Nick Kew's words). By this rule I understand that a
module itself shouldn't be bothered creating and managing threads and
it shouldn't do assumptions about the environment where it runs. In
other words one has to keep in mind that code could be either running in
one of many threads or be the only thread of a child server, whence the
second general rule I found explicitly stated: global data must be
always accessed after a lock on a specific (APR) Mutex has been gained.
Otherwise said: if you don't know your whereabouts assume you're in a
thread.
Tcl's threading shouldn't be involved here: in this model Apache has the
duty of managing threads. Interpreters within a thread will be real
independent interpreters without any chance to communicate through the
mechanisms Tcl's Threads provide.
I expect the mpm worker to use some hook to initialize a thread in a
similar way it does for a child process (perhaps the same hook is called
for each process and thread alike). In this scheme Rivet would end up
creating a potentially large number of interpreters:
num_of_children * number_of_virtual_hosts * number_of_threads_per_child
That makes Karl's concerns about interpreters proliferation more
dramatic....
-- Massimo
On 07/29/2011 08:40 PM, Karl Lehenbauer wrote:
> I know Tcl's thread model is one interpreter per thread. That seems like
> a pretty good fit. Is it even relevant?
>
> On 7/29/11 1:16 PM, "Damon Courtney"<da...@tclhome.com> wrote:
>
>> I don't recall being the one to addd that code, but I would imagine we
>> need to go with Apache's model here. We run inside Apache's world, for
>> the most part, so we should let that be the record of authority in cases
>> like these.
>>
>> Damon
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Tcl_Mutex call
Posted by Damon Courtney <da...@tclhome.com>.
Well, Massimo says it doesn't work as it is right now, and I've seen some mail on this list to that effect as well, so there must be something wonky going on there. I have no idea what though. 0-]
Damon
On Jul 29, 2011, at 1:40 PM, Karl Lehenbauer wrote:
> I know Tcl's thread model is one interpreter per thread. That seems like
> a pretty good fit. Is it even relevant?
>
> On 7/29/11 1:16 PM, "Damon Courtney" <da...@tclhome.com> wrote:
>
>> I don't recall being the one to addd that code, but I would imagine we
>> need to go with Apache's model here. We run inside Apache's world, for
>> the most part, so we should let that be the record of authority in cases
>> like these.
>>
>> Damon
>>
>>
>> On Jul 29, 2011, at 12:39 PM, Massimo Manghi wrote:
>>
>>> Hi guys
>>>
>>> I'm reviewing mod_rivet.c to understand what
>>> making it mpm-worker compliant is about. Currently mod_rivet
>>> fails miserably when running with the threaded mpm,
>>> still this is an issue we should try to
>>> deal with.
>>>
>>> It seems someone (Damon?) laid down the code
>>> setting up Rivet to support threads by putting the
>>> content generation within a pair of
>>> Tcl_MutexLock-Tcl_MutexUnlock calls.
>>> I don't see any other purpose for this and there is
>>> no comment explaining the need for this. I
>>>
>>> This is not enought to let it work and anyway
>>> Rivet should use apr_* call to better suit the Apache
>>> threading model.
>>>
>>> Anyone can recall why these calls made it into the code?
>>>
>>> -- Massimo
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Tcl_Mutex call
Posted by Karl Lehenbauer <ka...@gmail.com>.
I know Tcl's thread model is one interpreter per thread. That seems like
a pretty good fit. Is it even relevant?
On 7/29/11 1:16 PM, "Damon Courtney" <da...@tclhome.com> wrote:
>I don't recall being the one to addd that code, but I would imagine we
>need to go with Apache's model here. We run inside Apache's world, for
>the most part, so we should let that be the record of authority in cases
>like these.
>
>Damon
>
>
>On Jul 29, 2011, at 12:39 PM, Massimo Manghi wrote:
>
>> Hi guys
>>
>> I'm reviewing mod_rivet.c to understand what
>> making it mpm-worker compliant is about. Currently mod_rivet
>> fails miserably when running with the threaded mpm,
>> still this is an issue we should try to
>> deal with.
>>
>> It seems someone (Damon?) laid down the code
>> setting up Rivet to support threads by putting the
>> content generation within a pair of
>> Tcl_MutexLock-Tcl_MutexUnlock calls.
>> I don't see any other purpose for this and there is
>> no comment explaining the need for this. I
>>
>> This is not enought to let it work and anyway
>> Rivet should use apr_* call to better suit the Apache
>> threading model.
>>
>> Anyone can recall why these calls made it into the code?
>>
>> -- Massimo
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Tcl_Mutex call
Posted by Damon Courtney <da...@tclhome.com>.
I don't recall being the one to addd that code, but I would imagine we need to go with Apache's model here. We run inside Apache's world, for the most part, so we should let that be the record of authority in cases like these.
Damon
On Jul 29, 2011, at 12:39 PM, Massimo Manghi wrote:
> Hi guys
>
> I'm reviewing mod_rivet.c to understand what
> making it mpm-worker compliant is about. Currently mod_rivet
> fails miserably when running with the threaded mpm,
> still this is an issue we should try to
> deal with.
>
> It seems someone (Damon?) laid down the code
> setting up Rivet to support threads by putting the
> content generation within a pair of
> Tcl_MutexLock-Tcl_MutexUnlock calls.
> I don't see any other purpose for this and there is
> no comment explaining the need for this. I
>
> This is not enought to let it work and anyway
> Rivet should use apr_* call to better suit the Apache
> threading model.
>
> Anyone can recall why these calls made it into the code?
>
> -- Massimo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org