apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: bug in apr_os_thread_current ?
Date Mon, 25 Nov 2002 04:32:59 GMT
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




Mime
View raw message