httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <sor...@gmail.com>
Subject Re: thread ID
Date Thu, 01 Mar 2012 23:34:29 GMT
On 03/02/12 00:21, Ben Noordhuis wrote:
> On Thu, Mar 1, 2012 at 17:29,<sorin.manolache@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



Mime
View raw message