Re: nested mutexes in 1.0 (was Re: cvs commit: apr/locks/unix thread_mutex.c)

["William A. Rowe, Jr." <wr...@apache.org>]

-1 veto not vote.  If we cannot support it, we cannot use it internally.

Bill

At 12:50 PM 11/17/2003, Aaron Bannert wrote:
>On Mon, Nov 17, 2003 at 06:11:06AM -0500, Joe Orton wrote:
>> On Sun, Nov 16, 2003 at 06:25:00PM -0000, Jeff Trawick wrote:
>> > trawick     2003/11/16 10:25:00
>> > 
>> >   Modified:    locks/unix thread_mutex.c
>> >   Log:
>> >   thread id is not always a scalar
>> 
>> This nested mutex code still relies on behavior which is either
>> explicitly "undefined" by POSIX, or it's just wrong.  For 1.0 I think it
>> would be best not to advertise the APR_THREAD_MUTEX_NESTED flag in the
>> API.  e.g. remove it from the public header and move it to a private
>> header to allow the pool-debug code to still build.
>
>+1
>
>Does the debug code actually need it, or can we change the way it uses
>mutexes so that it doesn't?
>
>-aaron

Re: nested mutexes in 1.0 (was Re: cvs commit: apr/locks/unix thread_mutex.c)

["William A. Rowe, Jr." <wr...@apache.org>]

At 03:29 PM 11/17/2003, William A. Rowe, Jr. wrote:
>-1 veto not vote.  If we cannot support it, we cannot use it internally.

I want to make sure folks understand what my objection is;

if we drop NESTED v.s. UNNESTED I'm fine with that.  

Moving the choice to a private header so we can use it,
but we don't expose it, is altogether bogus, IMHO.

Bill