apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
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
Date Mon, 20 Nov 2006 20:43:34 GMT
William A. Rowe, Jr. wrote:
> 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?

Sorry ... busybusybusy ... but I agree with you that this should work.

> 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.

And I just can't help here right now. No time to breathe.

View raw message