You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/11/17 12:50:34 UTC
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
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.
Other opinions before Mladen or I proceed?
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
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.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
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.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Nov 20, 2006 at 02:30:33PM -0600, William A. Rowe, Jr. wrote:
> > Other opinions before Mladen or I proceed?
>
> I'm not happy with the silence here... feedback please?
Considering that this commit busted Subversion on Win32 and other conceptual
arguments against this change (which I'm admittedly not the best judge of - but
when OtherBill and Brane agree, I'm sure it's right), so +1 for reverting this
commit. -- justin
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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