thread ID

[so...@orange.com]

Hello,

I would need a memory buffer associated per worker thread (in the worker 
MPM) or to each process (in the prefork MPM).

In order to do that, I would need a map thread<->buffer. So, I would 
need a sort of thread ID/key/handle that stays the same during the 
lifetime of the thread and no two threads in the same process can have 
the same ID/key/handle.

What is the most portable way to get this thread ID?

I thought of r->connection->id. It works but it is not very portable as 
it is not guaranteed that two connections created by the same thread 
will have the same id. They do for now.

If r->connection->sbh was not opaque it would be great, because 
sbh->thread_num would be exactly what I need.

I could also use pthread_self. It works too but, in general, it is not 
guaranteed that the worker threads are pthreads.


Thank you for your help.

Sorin
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

Re: thread ID

[Rainer Jung <ra...@kippdata.de>]

On 06.03.2012 09:25, Massimo Manghi wrote:
> I'm quite aware the code is public, but I thought it would be highly
> recommended to rely on interfaces rather than copying & pasting
> implementations that might change in future.
>
> Days ago I put on this list a question (that went unanswered) concerning
> the proper way to infer the running mpm name. A core function
> ap_mpm_name exists, but apparently it's not public. I gather from this
> thread the conclusion that reproducing the code of the function could be
> a way to get the information I sought. I don't like it, but at least I
> have a way to get around my problem.

Of course using a public API is much better. In both cases there is none 
available. Copying code gets problematic, when you start to use e.g. 
struct members which are not guaranteed to remain unchanged.

Concerning the MPM name: If you really are trying to find out, whether 
an MPM is multi threaded or not, you can use the public MPM query API. 
It allows to pose questions on the behaviour and config of an MPM and 
should be better than to rely on its name in many cases.

threadId: if you look at log_tid() you will see, that it does not rely 
on any private API or detailed knowledge abut struct internals. So 
copying code here should be stable. At least if I didn't miss something.

Regards,

Rainer

Re: thread ID

[Massimo Manghi <ma...@unipr.it>]

I'm quite aware the code is public, but I thought it would be highly 
recommended to rely on interfaces rather than copying & pasting 
implementations that might change in future.

Days ago I put on this list a question (that went unanswered) concerning 
the proper way to infer the running mpm name. A core function 
ap_mpm_name exists, but apparently it's not public. I gather from this 
thread the conclusion that reproducing the code of the function could be 
a way to get the information I sought. I don't like it, but at least I 
have a way to get around my problem.

thanks

  -- Massimo


On 03/05/2012 08:21 PM, Rainer Jung wrote:
> On 05.03.2012 11:33, Massimo Manghi wrote:
>>
>> true, the ID is logged now, but is the function handling the thread id
>> public?
>
> not the function, but the source. See function log_tid() in server/log.c.
>
> Regards,
>
> Rainer

Re: thread ID

[Rainer Jung <ra...@kippdata.de>]

On 05.03.2012 11:33, Massimo Manghi wrote:
> On 03/03/2012 07:04 PM, Rainer Jung wrote:
>> On 02.03.2012 00:34, Sorin Manolache wrote:
>>> On 03/02/12 00:21, Ben Noordhuis wrote:
>>>> On Thu, Mar 1, 2012 at 17:29,<so...@orange.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I would need a memory buffer associated per worker thread (in the
>>>>> worker
>>>>> MPM) or to each process (in the prefork MPM).
>>>>>
>>>>> In order to do that, I would need a map thread<->buffer. So, I would
>>>>> need a sort of thread ID/key/handle that stays the same during the
>>>>> lifetime of the thread and no two threads in the same process can have
>>>>> the same ID/key/handle.
>>>>>
>>>>> What is the most portable way to get this thread ID?
>>>>>
>>>>> I thought of r->connection->id. It works but it is not very
>>>>> portable as
>>>>> it is not guaranteed that two connections created by the same thread
>>>>> will have the same id. They do for now.
>>>>>
>>>>> If r->connection->sbh was not opaque it would be great, because
>>>>> sbh->thread_num would be exactly what I need.
>>>>>
>>>>> I could also use pthread_self. It works too but, in general, it is not
>>>>> guaranteed that the worker threads are pthreads.
>>>>>
>>>>>
>>>>> Thank you for your help.
>>>>>
>>>>> Sorin
>>>>
>>>> What about apr_os_thread_current()? It returns a opaque value that's a
>>>> pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to
>>>> understand what that means.
>>>>
>>>> As a recovering standards lawyer I should probably point out that
>>>> pthread_t is an opaque type that's not guaranteed to be convertible to
>>>> a numeric value (or to anything, really). That said, I've never seen a
>>>> pthreads implementation where that wasn't the case.
>>>>
>>>> [1]
>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx
>>>>
>>>>
>>>
>>> Thank you, it's what I need.
>>
>> You might also want to check the function log_tid() in server/log.c of
>> httpd's trunk or 2.4. The thread id gets logged in the error log by
>> default since 2.4, so that code converts it to a number.
>>
>> Regards,
>>
>> Rainer
>
> true, the ID is logged now, but is the function handling the thread id
> public?

not the function, but the source. See function log_tid() in server/log.c.

Regards,

Rainer

Re: thread ID

[Massimo Manghi <ma...@unipr.it>]

On 03/03/2012 07:04 PM, Rainer Jung wrote:
> On 02.03.2012 00:34, Sorin Manolache wrote:
>> On 03/02/12 00:21, Ben Noordhuis wrote:
>>> On Thu, Mar 1, 2012 at 17:29,<so...@orange.com> wrote:
>>>> Hello,
>>>>
>>>> I would need a memory buffer associated per worker thread (in the 
>>>> worker
>>>> MPM) or to each process (in the prefork MPM).
>>>>
>>>> In order to do that, I would need a map thread<->buffer. So, I would
>>>> need a sort of thread ID/key/handle that stays the same during the
>>>> lifetime of the thread and no two threads in the same process can have
>>>> the same ID/key/handle.
>>>>
>>>> What is the most portable way to get this thread ID?
>>>>
>>>> I thought of r->connection->id. It works but it is not very 
>>>> portable as
>>>> it is not guaranteed that two connections created by the same thread
>>>> will have the same id. They do for now.
>>>>
>>>> If r->connection->sbh was not opaque it would be great, because
>>>> sbh->thread_num would be exactly what I need.
>>>>
>>>> I could also use pthread_self. It works too but, in general, it is not
>>>> guaranteed that the worker threads are pthreads.
>>>>
>>>>
>>>> Thank you for your help.
>>>>
>>>> Sorin
>>>
>>> What about apr_os_thread_current()? It returns a opaque value that's a
>>> pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to
>>> understand what that means.
>>>
>>> As a recovering standards lawyer I should probably point out that
>>> pthread_t is an opaque type that's not guaranteed to be convertible to
>>> a numeric value (or to anything, really). That said, I've never seen a
>>> pthreads implementation where that wasn't the case.
>>>
>>> [1]
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx 
>>>
>>>
>>
>> Thank you, it's what I need.
>
> You might also want to check the function log_tid() in server/log.c of 
> httpd's trunk or 2.4. The thread id gets logged in the error log by 
> default since 2.4, so that code converts it to a number.
>
> Regards,
>
> Rainer

true, the ID is logged now, but is the function handling the thread id 
public?

  -- Massimo

Re: thread ID

[Rainer Jung <ra...@kippdata.de>]

On 02.03.2012 00:34, Sorin Manolache wrote:
> On 03/02/12 00:21, Ben Noordhuis wrote:
>> On Thu, Mar 1, 2012 at 17:29,<so...@orange.com> wrote:
>>> Hello,
>>>
>>> I would need a memory buffer associated per worker thread (in the worker
>>> MPM) or to each process (in the prefork MPM).
>>>
>>> In order to do that, I would need a map thread<->buffer. So, I would
>>> need a sort of thread ID/key/handle that stays the same during the
>>> lifetime of the thread and no two threads in the same process can have
>>> the same ID/key/handle.
>>>
>>> What is the most portable way to get this thread ID?
>>>
>>> I thought of r->connection->id. It works but it is not very portable as
>>> it is not guaranteed that two connections created by the same thread
>>> will have the same id. They do for now.
>>>
>>> If r->connection->sbh was not opaque it would be great, because
>>> sbh->thread_num would be exactly what I need.
>>>
>>> I could also use pthread_self. It works too but, in general, it is not
>>> guaranteed that the worker threads are pthreads.
>>>
>>>
>>> Thank you for your help.
>>>
>>> Sorin
>>
>> What about apr_os_thread_current()? It returns a opaque value that's a
>> pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to
>> understand what that means.
>>
>> As a recovering standards lawyer I should probably point out that
>> pthread_t is an opaque type that's not guaranteed to be convertible to
>> a numeric value (or to anything, really). That said, I've never seen a
>> pthreads implementation where that wasn't the case.
>>
>> [1]
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx
>>
>
> Thank you, it's what I need.

You might also want to check the function log_tid() in server/log.c of 
httpd's trunk or 2.4. The thread id gets logged in the error log by 
default since 2.4, so that code converts it to a number.

Regards,

Rainer

Re: thread ID

[Sorin Manolache <so...@gmail.com>]

On 03/02/12 00:21, Ben Noordhuis wrote:
> On Thu, Mar 1, 2012 at 17:29,<so...@orange.com>  wrote:
>> Hello,
>>
>> I would need a memory buffer associated per worker thread (in the worker
>> MPM) or to each process (in the prefork MPM).
>>
>> In order to do that, I would need a map thread<->buffer. So, I would
>> need a sort of thread ID/key/handle that stays the same during the
>> lifetime of the thread and no two threads in the same process can have
>> the same ID/key/handle.
>>
>> What is the most portable way to get this thread ID?
>>
>> I thought of r->connection->id. It works but it is not very portable as
>> it is not guaranteed that two connections created by the same thread
>> will have the same id. They do for now.
>>
>> If r->connection->sbh was not opaque it would be great, because
>> sbh->thread_num would be exactly what I need.
>>
>> I could also use pthread_self. It works too but, in general, it is not
>> guaranteed that the worker threads are pthreads.
>>
>>
>> Thank you for your help.
>>
>> Sorin
>
> What about apr_os_thread_current()? It returns a opaque value that's a
> pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to
> understand what that means.
>
> As a recovering standards lawyer I should probably point out that
> pthread_t is an opaque type that's not guaranteed to be convertible to
> a numeric value (or to anything, really). That said, I've never seen a
> pthreads implementation where that wasn't the case.
>
> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx

Thank you, it's what I need.

Sorin

Re: thread ID

[Ben Noordhuis <in...@bnoordhuis.nl>]

On Thu, Mar 1, 2012 at 17:29,  <so...@orange.com> wrote:
> Hello,
>
> I would need a memory buffer associated per worker thread (in the worker
> MPM) or to each process (in the prefork MPM).
>
> In order to do that, I would need a map thread<->buffer. So, I would
> need a sort of thread ID/key/handle that stays the same during the
> lifetime of the thread and no two threads in the same process can have
> the same ID/key/handle.
>
> What is the most portable way to get this thread ID?
>
> I thought of r->connection->id. It works but it is not very portable as
> it is not guaranteed that two connections created by the same thread
> will have the same id. They do for now.
>
> If r->connection->sbh was not opaque it would be great, because
> sbh->thread_num would be exactly what I need.
>
> I could also use pthread_self. It works too but, in general, it is not
> guaranteed that the worker threads are pthreads.
>
>
> Thank you for your help.
>
> Sorin

What about apr_os_thread_current()? It returns a opaque value that's a
pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to
understand what that means.

As a recovering standards lawyer I should probably point out that
pthread_t is an opaque type that's not guaranteed to be convertible to
a numeric value (or to anything, really). That said, I've never seen a
pthreads implementation where that wasn't the case.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx