Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <5.1.0.14.2.20021124214455.03cec008@pop3.rowe-clan.net>
Date: Sun, 24 Nov 2002 22:32:59 -0600
To: Marcel.Mann@dbaudio.com
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: bug in apr_os_thread_current ? 
Cc: dev@apr.apache.org
In-Reply-To: <OF59BAF49D.B1F83CAF-ONC1256C78.0059C84A@dbaudio.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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