Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45621069.7070607@rowe-clan.net>
Date: Mon, 20 Nov 2006 14:30:33 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: Mladen Turk <mturk@apache.org>, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?=
 <brane@xbc.nu>,  dev@apr.apache.org,  commits@apr.apache.org
Subject: Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES
 include/arch/win32/apr_arch_threadproc.h
 misc/win32/start.c threadproc/win32/threadpriv.c
References: <20060824072438.7C0B61A981A@eris.apache.org>
 <44F08D91.60703@rowe-clan.net> <44F42B13.1050407@apache.org>
 <44F430C3.4020102@xbc.nu> <44FDB007.7080604@apache.org>
 <455DA20A.7000407@rowe-clan.net>
In-Reply-To: <455DA20A.7000407@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Since all this is a hack, IMHO we can simply exploit the
>> feature from DLL apr build, and leave the current
>> status for LIB builds like it was before.
>> (BTW, my patch does that).
> 
> Given the choice between supporting all architectures except amd64, or
> supporting only .dll's, I vote for the former.  That's -1 to the code
> living in trunk.
> 
> The DLL thing is a 'hack' - something that doesn't solve the whole issue
> but works around the problem in front of you.  The CRT linkage is by design
> in the PE format, the only hacks needed are to resolve why certain PE flavors
> are being handled differently than others, and writing the #if arch logic
> to handle this or leave it unresolved for an architecture.
> 
> Native-64 is going to seriously underperform 32 bit compilations for 95% of
> applications in the first place.  But it's entirely reasonable (and common)
> for developers to decide to roll out a monolithic .exe binary.

One more thought on the Native-64 issue; this is SUPPOSED to be supported by
the Windows PE format.  Either we did something wrong or it's a bug in the
compiler (and since they are soliciting feedback for SP1 it's a good thing to
point out, I'll see if we can't fast track it.)

But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the
PE solution solves 100% of the cases, sans bugs.

> Other opinions before Mladen or I proceed?

I'm not happy with the silence here... feedback please?

There's another issue - we've been debating a 'fix' without any test case, and
really can't have a code shootout without some test case in place that validates
the two possible solutions.

Bill