bug in apr_os_thread_current ?

[Ma...@dbaudio.com]

Hi,

as documented, apr_os_thread_current() returns the id for the current 
thread. 
The WIN32 version calls GetCurrentThread(). GetCurrentThread returns a 
pseudo handle for the current thread, not the id.
GetCurrentThreadId() returns the id.

APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
Last modified at [$Date: 2002/08/22 20:16:23 $]

Regards,
Marcel

Re: bug in apr_os_thread_current ?

[Aaron Bannert <aa...@clove.org>]

On Saturday, November 23, 2002, at 10:39  PM, Justin Erenkrantz wrote:

> --On Friday, November 22, 2002 6:51 AM -0600 "William A. Rowe, Jr." 
> <wr...@apache.org> wrote:
>
>> Agreed that it is a bug.  The question is whether it even makes
>> sense to use the thread handle or thread ID.
>>
>> Who is using apr_os_thread_current() and if so, what are you
>> plugging it into?
>
> FWIW, flood is using it as various locations to provide unique 
> per-process ids (OpenSSL requires unique thread ids in order to be 
> threadsafe).  But, it's not passing them to a native OS call, so the 
> value doesn't really matter.  -- justin

Yeah, and as soon as we come up with something better, we will stop
using it in this way. It was a temporary hack to get a unique integer
for each "farmer".

-aaron

Re: bug in apr_os_thread_current ?

[Justin Erenkrantz <je...@apache.org>]

--On Friday, November 22, 2002 6:51 AM -0600 "William A. Rowe, Jr." 
<wr...@apache.org> wrote:

> Agreed that it is a bug.  The question is whether it even makes
> sense to use the thread handle or thread ID.
>
> Who is using apr_os_thread_current() and if so, what are you
> plugging it into?

FWIW, flood is using it as various locations to provide unique 
per-process ids (OpenSSL requires unique thread ids in order to be 
threadsafe).  But, it's not passing them to a native OS call, so the 
value doesn't really matter.  -- justin

Re: bug in apr_os_thread_current ?

["William A. Rowe, Jr." <wr...@apache.org>]

Agreed that it is a bug.  The question is whether it even makes sense
to use the thread handle or thread ID.

Who is using apr_os_thread_current() and if so, what are you plugging
it into?

At 10:34 AM 11/21/2002, Marcel.Mann@dbaudio.com wrote:

>Hi, 
>
>as documented, apr_os_thread_current() returns the id for the current thread. 
>The WIN32 version calls GetCurrentThread(). GetCurrentThread returns a pseudo handle for the current thread, not the id. 
>GetCurrentThreadId() returns the id. 
>
>APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: 
>Last modified at [$Date: 2002/08/22 20:16:23 $] 
>
>Regards, 
>Marcel 

Re: bug in apr_os_thread_current ?

["William A. Rowe, Jr." <wr...@apache.org>]

At 10:34 AM 11/21/2002, Marcel.Mann@dbaudio.com wrote:

>Hi, 
>
>as documented, apr_os_thread_current() returns the id for the current thread. 
>The WIN32 version calls GetCurrentThread(). GetCurrentThread returns a pseudo handle for the current thread, not the id. 
>GetCurrentThreadId() returns the id. 

Ok, that's icky and sticky and full of bleck.

The problem we have is that apr_os_thread_current() need to return a HANDLE.
However --- if we return a real handle, it's up to the caller to close it.  We don't
have so much as a pool context to know when to clean it up ourselves.

OTOH, apr_os_thread_get() returns the real HANDLE that the user damned
well better not close, since we use it internally within APR.

The best answer is to return the handle we are using internally, I'm thinking
along the lines of dummy_worker() using TlsSetValue() to cache our 'internal'
handle we use for the lifetime of the thread.  Since nobody 'aught' to be
closing that handle, it should be appropriate to return it.  TlsGetValue() can
retrieve such data on a per-thread basis.

I'm tempted to simply cache the apr_thread_t* so we really can get back
at any data we need later.

Anyone have other thoughts?

Bill