Date: Fri, 29 Oct 2004 17:20:48 -0700 From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: MFC req for 5.x/5.3 Message-ID: <4182DE60.8030805@elischer.org> In-Reply-To: <4182D91F.6020603@freebsd.org> References: <Pine.GSO.4.43.0410281908000.5783-100000@sea.ntplx.net> <41817EE4.9080302@elischer.org> <20041029010822.GA12081@electra.cse.Buffalo.EDU> <20041029040931.GA920@frontfree.net> <4182A431.2050001@elischer.org> <20041029202458.GE9533@electra.cse.Buffalo.EDU> <4182D91F.6020603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
when compiling these against RELENG_5 I see a couple of warnings in
libpthread..
cc -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include
-I/usr/s
rc/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include
-I/usr/src/lib
/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys
-I/usr/src/lib/libpt
hread/../../libexec/rtld-elf
-I/usr/src/lib/libpthread/../../libexec/rtld-elf/i3
86 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall
-I/usr/src/lib/libpth
read/../libc/i386 -c /usr/src/lib/libpthread/thread/thr_kern.c
/usr/src/lib/libpthread/thread/thr_kern.c: In function `_kse_alloc':
/usr/src/lib/libpthread/thread/thr_kern.c:2204: warning: 'crit' might be
used un
initialized in this function
cc -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include
-I/usr/s
rc/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include
-I/usr/src/lib
/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys
-I/usr/src/lib/libpt
hread/../../libexec/rtld-elf
-I/usr/src/lib/libpthread/../../libexec/rtld-elf/i3
86 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall
-I/usr/src/lib/libpth
read/../libc/i386 -c /usr/src/lib/libpthread/thread/thr_mutex.c
/usr/src/lib/libpthread/thread/thr_mutex.c: In function
`_pthread_mutex_init':
/usr/src/lib/libpthread/thread/thr_mutex.c:111: warning: 'type' might be
used un
initialized in this function
/usr/src/lib/libpthread/thread/thr_mutex.c:112: warning: 'protocol'
might be use
d uninitialized in this function
/usr/src/lib/libpthread/thread/thr_mutex.c:113: warning: 'ceiling' might
be used
uninitialized in this function
/usr/src/lib/libpthread/thread/thr_mutex.c:114: warning: 'flags' might
be used u
ninitialized in this function
cc -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include
-I/usr/s
rc/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include
-I/usr/src/lib
/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys
-I/usr/src/lib/libpt
hread/../../libexec/rtld-elf
-I/usr/src/lib/libpthread/../../libexec/rtld-elf/i3
86 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall
-I/usr/src/lib/libpth
read/../libc/i386 -c /usr/src/lib/libpthread/thread/thr_sem.c
/usr/src/lib/libpthread/thread/thr_sem.c: In function `_sem_init':
/usr/src/lib/libpthread/thread/thr_sem.c:126: warning: assignment makes
integer
from pointer without a cast
cc -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include
-I/usr/s
rc/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include
-I/usr/src/lib
/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys
-I/usr/src/lib/libpt
hread/../../libexec/rtld-elf
-I/usr/src/lib/libpthread/../../libexec/rtld-elf/i3
86 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall
-I/usr/src/lib/libpth
read/../libc/i386 -c /usr/src/lib/libpthread/thread/thr_symbols.c
In file included from
/usr/src/lib/libpthread/../../libexec/rtld-elf/rtld.h:40,
from /usr/src/lib/libpthread/thread/thr_symbols.c:37:
/usr/src/lib/libpthread/../../libexec/rtld-elf/i386/rtld_machdep.h: In
function
`reloc_jmpslot':
/usr/src/lib/libpthread/../../libexec/rtld-elf/i386/rtld_machdep.h:49:
warning:
implicit declaration of function `dbg'
Dan/David.. any of these anything to worry about? if not I'll commit to
RELENG_5
David Xu wrote:
> Ken Smith wrote:
>
>> Yup. That's why I thought we would need to be a little bit careful
>> with this, it's a bit more complicated than it first seems. There
>> is a chance for example that a piece that's not being MFC-ed added
>> an extra #include and if the new code that's being MFC-ed relies on
>> that it can be a bit tough to catch with the first attempt. My
>> asking for caution on this wasn't a reflection on Julian, I'd ask
>> anyone to be this careful about this particular MFC because it doesn't
>> look like it's a straight "MFC everything". And doing an "MFC
>> everything"
>> for a library like this is risky at the RC2 stage, it's possible pieces
>> of what gets swept in could have an impact (possibly negative) on the
>> packages that use it. It would be a bit of a gamble.
>>
>> Thanks for your work on this guys. Greatly appreciated.
>>
>>
>>
> Because the library in RELENG_5 can not pass my stress test:
> http://people.freebsd.org/~davidxu/thread_stress/joinstress.c
> I think it is a real world test case for web server like program,
> without this patches, I don't think libpthread can be used under
> heavily loaded environment.
>
> David Xu
>
> _______________________________________________
> freebsd-threads@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to
> "freebsd-threads-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4182DE60.8030805>