You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by INOUE Seiichiro <in...@ariel-networks.com> on 2002/09/05 21:54:33 UTC

apr_os_thread_get() weirdness on Win32

Hi,

It looks apr_os_thread_get() is wrong on Win32.
The types don't match.

Excerpted from "include/apr_portable.h"
typedef HANDLE                apr_os_thread_t;

Excerpted from "include/arch/win32/threadproc.h"
struct apr_thread_t {
    apr_pool_t *pool;
    HANDLE td;
    ...

Excerpted from "threadproc/win32/thread.c"
APR_DECLARE(apr_status_t) apr_os_thread_get(apr_os_thread_t **thethd,
                                            apr_thread_t *thd)
{
    if (thd == NULL) {
        return APR_ENOTHREAD;
    }
    *thethd = thd->td;
    return APR_SUCCESS;
}


Thanks.
- INOUE Seiichiro <in...@ariel-networks.com>

Re: [Resend] Re: apr_os_thread_get() weirdness on Win32

Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 10:33 AM 12/24/2002, INOUE Seiichiro wrote:
>This is an old story.
>I would like to make it clear.
>
>When we need the Win32 thread handle from libapr, the following code is a proper code?
>
>HANDLE h;
>apr_thread_t *thd;
>apr_os_thread_get((apr_os_thread_t**)&h, thd);

Hes, it should be.  And the cast should be unnecessary ... if it is,
we have a bug.

On win32, apr_thread_t should be a HANDLE already.

Bill


[Resend] Re: apr_os_thread_get() weirdness on Win32

Posted by INOUE Seiichiro <in...@ariel-networks.com>.
This is an old story.
I would like to make it clear.

When we need the Win32 thread handle from libapr, the following code is a proper code?

HANDLE h;
apr_thread_t *thd;
apr_os_thread_get((apr_os_thread_t**)&h, thd);


From: INOUE Seiichiro <in...@ariel-networks.com>
Subject: apr_os_thread_get() weirdness on Win32
Date: Fri, 06 Sep 2002 04:54:33 +0900 (JST)
> It looks apr_os_thread_get() is wrong on Win32.
> The types don't match.
> 
> Excerpted from "include/apr_portable.h"
> typedef HANDLE                apr_os_thread_t;
> 
> Excerpted from "include/arch/win32/threadproc.h"
> struct apr_thread_t {
>     apr_pool_t *pool;
>     HANDLE td;
>     ...
> 
> Excerpted from "threadproc/win32/thread.c"
> APR_DECLARE(apr_status_t) apr_os_thread_get(apr_os_thread_t **thethd,
>                                             apr_thread_t *thd)
> {
>     if (thd == NULL) {
>         return APR_ENOTHREAD;
>     }
>     *thethd = thd->td;
>     return APR_SUCCESS;
> }


From: Aaron Bannert <aa...@clove.org>
Subject: Re: apr_os_thread_get() weirdness on Win32
Date: Thu, 5 Sep 2002 13:06:50 -0700
> On Thu, Sep 05, 2002 at 04:01:17PM -0400, Cliff Woolley wrote:
> > On Fri, 6 Sep 2002, INOUE Seiichiro wrote:
> > 
> > > It looks apr_os_thread_get() is wrong on Win32.
> > > The types don't match.
> > 
> > I fail to see the problem?  apr_os_thread_get returns an apr_os_thread_t,
> > not an apr_thread_t.
> 
> It looks like there's a pointer mismatch, no? It'll work as long
> as you pass in a pointer to a HANDLE though, even if the types
> are quite right.


- INOUE Seiichiro <in...@ariel-networks.com>

Re: apr_os_thread_get() weirdness on Win32

Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 5 Sep 2002, Aaron Bannert wrote:

> It looks like there's a pointer mismatch, no? It'll work as long

Ahh... right you are.  Missed that.


Re: apr_os_thread_get() weirdness on Win32

Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Sep 05, 2002 at 04:01:17PM -0400, Cliff Woolley wrote:
> On Fri, 6 Sep 2002, INOUE Seiichiro wrote:
> 
> > It looks apr_os_thread_get() is wrong on Win32.
> > The types don't match.
> 
> I fail to see the problem?  apr_os_thread_get returns an apr_os_thread_t,
> not an apr_thread_t.

It looks like there's a pointer mismatch, no? It'll work as long
as you pass in a pointer to a HANDLE though, even if the types
are quite right.

-aaron

Re: apr_os_thread_get() weirdness on Win32

Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 6 Sep 2002, INOUE Seiichiro wrote:

> It looks apr_os_thread_get() is wrong on Win32.
> The types don't match.

I fail to see the problem?  apr_os_thread_get returns an apr_os_thread_t,
not an apr_thread_t.

--Cliff