You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian McCallister <br...@skife.org> on 2009/02/08 00:14:43 UTC
Getting pool associated with current thread/child
So, in mod_lua I need to get the apr pool associated with the current
thread (that being the main thread if in prefork).
Paul suggested that this is not possible, presently, and suggested
adding a current_thread field to the request_rec, which each mpm would
need to ensure is correct when it does things with the request (I
would be more specific, but "does things" is as detailed as I can go
at the moment ;-).
Alternately, an APR function like apr_current_thread(): *apr_thread_t,
would, I believe satisfy my need as I believe I can get the pool from
the thread struct.
Not sure the best path forward, suggestions?
-Brian
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Philip M. Gollucci wrote:
> Brian McCallister wrote:
>> So, in mod_lua I need to get the apr pool associated with the current
>> thread (that being the main thread if in prefork).
>>
>> Paul suggested that this is not possible, presently, and suggested
>> adding a current_thread field to the request_rec, which each mpm would
>> need to ensure is correct when it does things with the request (I
>> would be more specific, but "does things" is as detailed as I can go
>> at the moment ;-).
>>
>> Alternately, an APR function like apr_current_thread(): *apr_thread_t,
>> would, I believe satisfy my need as I believe I can get the pool from
>> the thread struct.
>>
>> Not sure the best path forward, suggestions?
>>
>> -Brian
>
> apr_os_thread_current()
> Its already in APR and IIRC, mod_perl is using it, is that not what you
> want ?
That gets you the os thread, aka a pthread_t.
It doesn't get you the apr_pool_t that APR has associated with its own
apr_thread_t that APR created when it made the thread.
I think the only way to do this is to extend the request rec, or
significantly change the APR API around threads and pools, with the
later being a much more complicated exercise
-Paul
Re: Getting pool associated with current thread/child
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Brian McCallister wrote:
> So, in mod_lua I need to get the apr pool associated with the current
> thread (that being the main thread if in prefork).
>
> Paul suggested that this is not possible, presently, and suggested
> adding a current_thread field to the request_rec, which each mpm would
> need to ensure is correct when it does things with the request (I
> would be more specific, but "does things" is as detailed as I can go
> at the moment ;-).
>
> Alternately, an APR function like apr_current_thread(): *apr_thread_t,
> would, I believe satisfy my need as I believe I can get the pool from
> the thread struct.
>
> Not sure the best path forward, suggestions?
>
> -Brian
apr_os_thread_current()
Its already in APR and IIRC, mod_perl is using it, is that not what you want ?
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior Sys Admin - RideCharge, Inc. http://ridecharge.com
Contractor - PositiveEnergyUSA http://positiveenergyusa.com
ASF Member - Apache Software Foundation http://apache.org
FreeBSD Committer - FreeBSD Foundation http://freebsd.org
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: Getting pool associated with current thread/child
Posted by Nick Kew <ni...@webthing.com>.
On 8 Feb 2009, at 07:06, Paul Querna wrote:
>> What about the process_rec structure?
>>
>> In other words, r->server->process->pool?
>>
>> (Not sure if this is what you are looking for, but a quick glance
>> at the
>> headers would suggest it probably does).
>
> that isn't thread safe to allocate from is it?
Even if you fix that, you'll leak anything you allocate from it.
--
Nick Kew
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Graham Leggett wrote:
> Brian McCallister wrote:
>
>> So, in mod_lua I need to get the apr pool associated with the current
>> thread (that being the main thread if in prefork).
>
> What about the process_rec structure?
>
> In other words, r->server->process->pool?
>
> (Not sure if this is what you are looking for, but a quick glance at the
> headers would suggest it probably does).
that isn't thread safe to allocate from is it?
AFAIK, that is just set once when the process record is created, and not
set or created per thread....
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Brian McCallister wrote:
> On Sun, Feb 8, 2009 at 5:05 PM, Brian McCallister <br...@skife.org> wrote:
>> On Sun, Feb 8, 2009 at 4:59 PM, Paul Querna <ch...@force-elite.com> wrote:
>>
>>> r742218 adds conn_rec::current_thread, and implements support for it on
>>> all the common Unix MPMs.....
>>>
>>> It turns out its really hard to use the request_rec in the MPMs, but yet
>>> again its in trouble of where we draw the lines between MPMs and
>>> everything else.
>> conn_rec is thread safe relative to the request_rec, so has same effect :-)
>
> Actually, is this a true statement?
Yes, a request_rec always has the same conn_rec, a conn_rec might just
be referenced from multiple request_recs, but requests are always
executed in serial on a single connection.
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
On Sun, Feb 8, 2009 at 5:05 PM, Brian McCallister <br...@skife.org> wrote:
> On Sun, Feb 8, 2009 at 4:59 PM, Paul Querna <ch...@force-elite.com> wrote:
>
>> r742218 adds conn_rec::current_thread, and implements support for it on
>> all the common Unix MPMs.....
>>
>> It turns out its really hard to use the request_rec in the MPMs, but yet
>> again its in trouble of where we draw the lines between MPMs and
>> everything else.
>
> conn_rec is thread safe relative to the request_rec, so has same effect :-)
Actually, is this a true statement?
-Brian (who thinks processes should be enough)
>
> Thanks!
>
> -Brian
>
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Brian McCallister wrote:
> On Sun, Feb 8, 2009 at 5:05 PM, Brian McCallister <br...@skife.org> wrote:
>> On Sun, Feb 8, 2009 at 4:59 PM, Paul Querna <ch...@force-elite.com> wrote:
>>
>>> r742218 adds conn_rec::current_thread, and implements support for it on
>>> all the common Unix MPMs.....
>>>
>>> It turns out its really hard to use the request_rec in the MPMs, but yet
>>> again its in trouble of where we draw the lines between MPMs and
>>> everything else.
>> conn_rec is thread safe relative to the request_rec, so has same effect :-)
>
> Speaking of, what is general policy on breaking modules re non-unix
> stuff? Is there any #define I can make use of to protect non-*nix
> stuff from it until the other mpms support it?
No, but I looked at taking a stab at the winnt MPM, hoping it would be
an easy fix, but it gets complicated because it doesn't have a root pool
for the thread, only a ptrans for the connection, which mean the patch
needs to be more complicated than exposing already created pools.
-Paul
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
On Sun, Feb 8, 2009 at 5:05 PM, Brian McCallister <br...@skife.org> wrote:
> On Sun, Feb 8, 2009 at 4:59 PM, Paul Querna <ch...@force-elite.com> wrote:
>
>> r742218 adds conn_rec::current_thread, and implements support for it on
>> all the common Unix MPMs.....
>>
>> It turns out its really hard to use the request_rec in the MPMs, but yet
>> again its in trouble of where we draw the lines between MPMs and
>> everything else.
>
> conn_rec is thread safe relative to the request_rec, so has same effect :-)
Speaking of, what is general policy on breaking modules re non-unix
stuff? Is there any #define I can make use of to protect non-*nix
stuff from it until the other mpms support it?
-Brian
>
> Thanks!
>
> -Brian
>
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
On Sun, Feb 8, 2009 at 4:59 PM, Paul Querna <ch...@force-elite.com> wrote:
> r742218 adds conn_rec::current_thread, and implements support for it on
> all the common Unix MPMs.....
>
> It turns out its really hard to use the request_rec in the MPMs, but yet
> again its in trouble of where we draw the lines between MPMs and
> everything else.
conn_rec is thread safe relative to the request_rec, so has same effect :-)
Thanks!
-Brian
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Brian McCallister wrote:
> On Sun, Feb 8, 2009 at 3:54 PM, Paul Querna <ch...@force-elite.com> wrote:
>
>> I think doing it via the mpm/extending the request rec is the right way
>> to do it, and I don't understand why there is resistance to just doing
>> it that way?
>
> I don't think there is resistance, it is just a chunk of code *I* am
> not comfortable making changes to as I do not grok it, yet.
>
> If you make such a change, or can point me to something to explain how
> they work, it seems like a good approach -- we'll just need to
> document that it is not safe to hold onto the pool if you use it.
r742218 adds conn_rec::current_thread, and implements support for it on
all the common Unix MPMs.....
It turns out its really hard to use the request_rec in the MPMs, but yet
again its in trouble of where we draw the lines between MPMs and
everything else.
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
On Sun, Feb 8, 2009 at 3:54 PM, Paul Querna <ch...@force-elite.com> wrote:
> I think doing it via the mpm/extending the request rec is the right way
> to do it, and I don't understand why there is resistance to just doing
> it that way?
I don't think there is resistance, it is just a chunk of code *I* am
not comfortable making changes to as I do not grok it, yet.
If you make such a change, or can point me to something to explain how
they work, it seems like a good approach -- we'll just need to
document that it is not safe to hold onto the pool if you use it.
-Brian
>
>
>>
>> On Sun, Feb 8, 2009 at 10:22 AM, Brian McCallister <br...@skife.org> wrote:
>>> On Sat, Feb 7, 2009 at 5:47 PM, Graham Leggett <mi...@sharp.fm> wrote:
>>>> Brian McCallister wrote:
>>>>
>>>>> So, in mod_lua I need to get the apr pool associated with the current
>>>>> thread (that being the main thread if in prefork).
>>>> What about the process_rec structure?
>>>>
>>>> In other words, r->server->process->pool?
>>> I thought this was one-per-process, where process is a real process. I
>>> need one-per-thread in in worker/event so that they don't step on each
>>> other.
>>>
>>> What I am looking for is to attach a lua_State instance to that pool,
>>> so that when the thread is retired, I can hook into cleanups, and so
>>> that I can attach the lua_State to the pool as userdata, to retrieve
>>> it later.
>>>
>>> In prefork, a process level pool would work fine, but AFAIK this is
>>> not a thread-safe thing.
>>>
>>>> (Not sure if this is what you are looking for, but a quick glance at the
>>>> headers would suggest it probably does).
>>>>
>>>> Regards,
>>>> Graham
>>>> --
>>>>
>
>
Re: Getting pool associated with current thread/child
Posted by Paul Querna <ch...@force-elite.com>.
Brian McCallister wrote:
> An alternative, for my need, is to be able to add a cleanup hook to
> the current thread. I can then just create a pool and put it in a
> thread local (you can do that with just the os thread in apr). I
> cannot find a way to actually register a cleanup for the threadlocal
> you set, though.
>
> Is there one which I am missing?
no, because there isn't a portable way to do it, and in addition it
would be an out of order pool destruction with the other pools, likely
causing other issues.
I think doing it via the mpm/extending the request rec is the right way
to do it, and I don't understand why there is resistance to just doing
it that way?
>
> On Sun, Feb 8, 2009 at 10:22 AM, Brian McCallister <br...@skife.org> wrote:
>> On Sat, Feb 7, 2009 at 5:47 PM, Graham Leggett <mi...@sharp.fm> wrote:
>>> Brian McCallister wrote:
>>>
>>>> So, in mod_lua I need to get the apr pool associated with the current
>>>> thread (that being the main thread if in prefork).
>>> What about the process_rec structure?
>>>
>>> In other words, r->server->process->pool?
>> I thought this was one-per-process, where process is a real process. I
>> need one-per-thread in in worker/event so that they don't step on each
>> other.
>>
>> What I am looking for is to attach a lua_State instance to that pool,
>> so that when the thread is retired, I can hook into cleanups, and so
>> that I can attach the lua_State to the pool as userdata, to retrieve
>> it later.
>>
>> In prefork, a process level pool would work fine, but AFAIK this is
>> not a thread-safe thing.
>>
>>> (Not sure if this is what you are looking for, but a quick glance at the
>>> headers would suggest it probably does).
>>>
>>> Regards,
>>> Graham
>>> --
>>>
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
An alternative, for my need, is to be able to add a cleanup hook to
the current thread. I can then just create a pool and put it in a
thread local (you can do that with just the os thread in apr). I
cannot find a way to actually register a cleanup for the threadlocal
you set, though.
Is there one which I am missing?
On Sun, Feb 8, 2009 at 10:22 AM, Brian McCallister <br...@skife.org> wrote:
> On Sat, Feb 7, 2009 at 5:47 PM, Graham Leggett <mi...@sharp.fm> wrote:
>> Brian McCallister wrote:
>>
>>> So, in mod_lua I need to get the apr pool associated with the current
>>> thread (that being the main thread if in prefork).
>>
>> What about the process_rec structure?
>>
>> In other words, r->server->process->pool?
>
> I thought this was one-per-process, where process is a real process. I
> need one-per-thread in in worker/event so that they don't step on each
> other.
>
> What I am looking for is to attach a lua_State instance to that pool,
> so that when the thread is retired, I can hook into cleanups, and so
> that I can attach the lua_State to the pool as userdata, to retrieve
> it later.
>
> In prefork, a process level pool would work fine, but AFAIK this is
> not a thread-safe thing.
>
>>
>> (Not sure if this is what you are looking for, but a quick glance at the
>> headers would suggest it probably does).
>>
>> Regards,
>> Graham
>> --
>>
>
Re: Getting pool associated with current thread/child
Posted by Brian McCallister <br...@skife.org>.
On Sat, Feb 7, 2009 at 5:47 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Brian McCallister wrote:
>
>> So, in mod_lua I need to get the apr pool associated with the current
>> thread (that being the main thread if in prefork).
>
> What about the process_rec structure?
>
> In other words, r->server->process->pool?
I thought this was one-per-process, where process is a real process. I
need one-per-thread in in worker/event so that they don't step on each
other.
What I am looking for is to attach a lua_State instance to that pool,
so that when the thread is retired, I can hook into cleanups, and so
that I can attach the lua_State to the pool as userdata, to retrieve
it later.
In prefork, a process level pool would work fine, but AFAIK this is
not a thread-safe thing.
>
> (Not sure if this is what you are looking for, but a quick glance at the
> headers would suggest it probably does).
>
> Regards,
> Graham
> --
>
Re: Getting pool associated with current thread/child
Posted by Graham Leggett <mi...@sharp.fm>.
Brian McCallister wrote:
> So, in mod_lua I need to get the apr pool associated with the current
> thread (that being the main thread if in prefork).
What about the process_rec structure?
In other words, r->server->process->pool?
(Not sure if this is what you are looking for, but a quick glance at the
headers would suggest it probably does).
Regards,
Graham
--