At 10:34 AM 11/21/2002, [EMAIL PROTECTED] 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
