From bugmaster at FreeBSD.org Mon Nov 2 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 2 11:09:48 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200911021107.nA2B74Q5033746@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From bugmaster at FreeBSD.org Mon Nov 9 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 9 11:09:35 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200911091107.nA9B74hW079138@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From bugmaster at FreeBSD.org Mon Nov 16 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 16 11:09:37 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200911161107.nAGB725P011312@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From lujiandong1001 at yahoo.com.cn Mon Nov 16 11:15:15 2009 From: lujiandong1001 at yahoo.com.cn (Jiandong Lu) Date: Mon Nov 16 12:28:52 2009 Subject: how to build libthr except other components of 'world' Message-ID: <885642.96228.qm@web15707.mail.cnb.yahoo.com> Hi,everyone, ??? I checkout FreeBSD?s source codes to my /usr/src ??? I use command ??? make buildworld ??? int directory /usr/src to build a world.I want to do some debug to lib /usr/src/lib/libthr.If I modified some files in /usr/src/lib/libthr/thread, how could I build libthr except other components of world? ?? btw,I execute command ?? make ?? in /usr/src/lib/libthr get this : cc -O2 -fno-strict-aliasing -pipe? -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread? -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/arch/i386/i386/pthread_md.c In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:33: /usr/src/lib/libthr/../../include/string.h:86: warning: no previous prototype for 'strdup' /usr/src/lib/libthr/../../include/string.h: In function 'strdup': /usr/src/lib/libthr/../../include/string.h:86: error: expected declaration specifiers before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:96: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:101: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:104: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__malloc_like' /usr/src/lib/libthr/../../include/string.h:105: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:108: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:110: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:111: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:118: warning: '__pure__' attribute ignored /usr/src/lib/libthr/../../include/string.h:119: warning: '__pure__' attribute ignored In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:34: /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:60: error: storage class specified for parameter '_rtld_allocate_tls' /usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:67: error: storage class specified for parameter '_rtld_free_tls' In file included from /usr/src/lib/libthr/arch/i386/include/pthread_md.h:36, ???????????????? from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36: /usr/src/lib/libthr/../../include/stddef.h:45: error: storage class specified for parameter 'ptrdiff_t' /usr/src/lib/libthr/../../include/stddef.h:49: error: storage class specified for parameter 'rune_t' /usr/src/lib/libthr/../../include/stddef.h:61: error: storage class specified for parameter 'wchar_t' In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36: /usr/src/lib/libthr/arch/i386/include/pthread_md.h:52: warning: empty declaration /usr/src/lib/libthr/arch/i386/include/pthread_md.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:95: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/include/pthread_md.h:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: old-style parameter declarations in prototyped function definition /usr/src/lib/libthr/../../include/string.h:86: error: parameter name omitted /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: expected '{' at end of input *** Error code 1 Stop in /usr/src/lib/libthr. ---------------------------------- thanks. ? ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From jhb at freebsd.org Thu Nov 19 15:30:23 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 15:30:30 2009 Subject: Using pthread_once() in libc Message-ID: <200911191030.14151.jhb@freebsd.org> I would like to provide a pthread_once()-like facility in libc that library bits can use to initialize data safely rather than trying to home-roll their own variants (see the recent commit to stdtime in libc). Ideally what I would like to do is have libc use the "real" pthread_once() when libthr is linked in and fall back to a simple stub without libthr linked in. I know we already do something like this for _spinlock() and friends. My question is what is the most correct way to do this? Should libc grow a new _once() symbol ala _spinlock() that is a weak symbol to a stub version and pthread_once() in thr_once.c would override that, or should there be a _pthread_once() in libc that is a stub in place of the current stub_zero? I noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for backwards compat. Does this mean that for the future we would like to expose pthread symbols directly in libc? Meaning would we rather have libc export a pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock instead of _spinlock/unlock? -- John Baldwin From deischen at freebsd.org Thu Nov 19 16:48:56 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Nov 19 16:49:03 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191030.14151.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> Message-ID: On Thu, 19 Nov 2009, John Baldwin wrote: > I would like to provide a pthread_once()-like facility in libc that library > bits can use to initialize data safely rather than trying to home-roll their > own variants (see the recent commit to stdtime in libc). Ideally what I > would like to do is have libc use the "real" pthread_once() when libthr is > linked in and fall back to a simple stub without libthr linked in. I know we > already do something like this for _spinlock() and friends. My question is > what is the most correct way to do this? Should libc grow a new _once() > symbol ala _spinlock() that is a weak symbol to a stub version and > pthread_once() in thr_once.c would override that, or should there be a > _pthread_once() in libc that is a stub in place of the current stub_zero? I > noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > backwards compat. Does this mean that for the future we would like to expose > pthread symbols directly in libc? Meaning would we rather have libc export a > pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > instead of _spinlock/unlock? pthread_once() is already a stub in libc that gets overloaded with the real thing when libthr is linked. See libc/gen/_pthread_stubs.c. Isn't that what you want or does it not serve your purpose? I think as soon as we get pthread lock types (at least mutex, cv's, and semaphores) implemented as structs instead of opaque pointers, then we can do away with the spinlocks. Currently, the library knows that spinlocks are different and plays games to avoid allocation problems at startup. At least that's my recollection. -- DE From jhb at freebsd.org Thu Nov 19 17:02:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 17:02:56 2009 Subject: Using pthread_once() in libc In-Reply-To: References: <200911191030.14151.jhb@freebsd.org> Message-ID: <200911191202.30738.jhb@freebsd.org> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > On Thu, 19 Nov 2009, John Baldwin wrote: > > > I would like to provide a pthread_once()-like facility in libc that library > > bits can use to initialize data safely rather than trying to home-roll their > > own variants (see the recent commit to stdtime in libc). Ideally what I > > would like to do is have libc use the "real" pthread_once() when libthr is > > linked in and fall back to a simple stub without libthr linked in. I know we > > already do something like this for _spinlock() and friends. My question is > > what is the most correct way to do this? Should libc grow a new _once() > > symbol ala _spinlock() that is a weak symbol to a stub version and > > pthread_once() in thr_once.c would override that, or should there be a > > _pthread_once() in libc that is a stub in place of the current stub_zero? I > > noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > > backwards compat. Does this mean that for the future we would like to expose > > pthread symbols directly in libc? Meaning would we rather have libc export a > > pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > > instead of _spinlock/unlock? > > pthread_once() is already a stub in libc that gets overloaded with the > real thing when libthr is linked. See libc/gen/_pthread_stubs.c. > Isn't that what you want or does it not serve your purpose? Hmm, the libc stub will never run the init routine. I would like to do something like this: Index: stdtime/localtime.c =================================================================== --- stdtime/localtime.c (revision 199529) +++ stdtime/localtime.c (working copy) @@ -235,9 +235,8 @@ static char lcl_TZname[TZ_STRLEN_MAX + 1]; static int lcl_is_set; -static int gmt_is_set; +static pthread_once_t gmt_once = PTHREAD_ONCE_INIT; static pthread_rwlock_t lcl_rwlock = PTHREAD_RWLOCK_INITIALIZER; -static pthread_mutex_t gmt_mutex = PTHREAD_MUTEX_INITIALIZER; char * tzname[2] = { wildabbr, @@ -1464,6 +1463,17 @@ return tmp; } +static void +gmt_init(void) +{ + +#ifdef ALL_STATE + gmtptr = (struct state *) malloc(sizeof *gmtptr); + if (gmtptr != NULL) +#endif /* defined ALL_STATE */ + gmtload(gmtptr); +} + /* ** gmtsub is to gmtime as localsub is to localtime. */ @@ -1476,16 +1486,7 @@ { register struct tm * result; - _MUTEX_LOCK(&gmt_mutex); - if (!gmt_is_set) { -#ifdef ALL_STATE - gmtptr = (struct state *) malloc(sizeof *gmtptr); - if (gmtptr != NULL) -#endif /* defined ALL_STATE */ - gmtload(gmtptr); - gmt_is_set = TRUE; - } - _MUTEX_UNLOCK(&gmt_mutex); + _pthread_once(&gmt_once, gmt_init); result = timesub(timep, offset, gmtptr, tmp); #ifdef TM_ZONE /* -- John Baldwin From jhb at freebsd.org Thu Nov 19 17:06:45 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 17:06:51 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191202.30738.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> Message-ID: <200911191206.40934.jhb@freebsd.org> On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote: > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > > On Thu, 19 Nov 2009, John Baldwin wrote: > > > > > I would like to provide a pthread_once()-like facility in libc that library > > > bits can use to initialize data safely rather than trying to home-roll their > > > own variants (see the recent commit to stdtime in libc). Ideally what I > > > would like to do is have libc use the "real" pthread_once() when libthr is > > > linked in and fall back to a simple stub without libthr linked in. I know we > > > already do something like this for _spinlock() and friends. My question is > > > what is the most correct way to do this? Should libc grow a new _once() > > > symbol ala _spinlock() that is a weak symbol to a stub version and > > > pthread_once() in thr_once.c would override that, or should there be a > > > _pthread_once() in libc that is a stub in place of the current stub_zero? I > > > noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > > > backwards compat. Does this mean that for the future we would like to expose > > > pthread symbols directly in libc? Meaning would we rather have libc export a > > > pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > > > instead of _spinlock/unlock? > > > > pthread_once() is already a stub in libc that gets overloaded with the > > real thing when libthr is linked. See libc/gen/_pthread_stubs.c. > > Isn't that what you want or does it not serve your purpose? > > Hmm, the libc stub will never run the init routine. I would like to do > something like this: Perhaps this would work to fix pthread_once: Index: gen/_pthread_stubs.c =================================================================== --- gen/_pthread_stubs.c (revision 199529) +++ gen/_pthread_stubs.c (working copy) @@ -51,6 +51,8 @@ static int stub_main(void); static void *stub_null(void); +static int stub_once(pthread_once_t *once_control, + void (*init_routine)(void)); static struct pthread *stub_self(void); static int stub_zero(void); static int stub_true(void); @@ -105,7 +107,7 @@ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_LOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_TRYLOCK */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_MUTEX_UNLOCK */ - {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_ONCE */ + {PJT_DUAL_ENTRY(stub_once)}, /* PJT_ONCE */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_DESTROY */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_INIT */ {PJT_DUAL_ENTRY(stub_zero)}, /* PJT_RWLOCK_RDLOCK */ @@ -301,3 +303,14 @@ { exit(0); } + +static int +stub_once(pthread_once_t *once_control, void (*init_routine)(void)) +{ + + if (once_control->state == ONCE_DONE) + return (0); + init_routine(); + once_control->state = ONCE_DONE; + return (0); +} -- John Baldwin From deischen at freebsd.org Thu Nov 19 17:09:35 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Nov 19 17:09:42 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191202.30738.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> Message-ID: On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >> On Thu, 19 Nov 2009, John Baldwin wrote: >> >>> I would like to provide a pthread_once()-like facility in libc that library >>> bits can use to initialize data safely rather than trying to home-roll their >>> own variants (see the recent commit to stdtime in libc). Ideally what I >>> would like to do is have libc use the "real" pthread_once() when libthr is >>> linked in and fall back to a simple stub without libthr linked in. I know we >>> already do something like this for _spinlock() and friends. My question is >>> what is the most correct way to do this? Should libc grow a new _once() >>> symbol ala _spinlock() that is a weak symbol to a stub version and >>> pthread_once() in thr_once.c would override that, or should there be a >>> _pthread_once() in libc that is a stub in place of the current stub_zero? I >>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for >>> backwards compat. Does this mean that for the future we would like to expose >>> pthread symbols directly in libc? Meaning would we rather have libc export a >>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock >>> instead of _spinlock/unlock? >> >> pthread_once() is already a stub in libc that gets overloaded with the >> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. >> Isn't that what you want or does it not serve your purpose? > > Hmm, the libc stub will never run the init routine. I would like to do > something like this: Well, I suppose you could do that. But what happens if libthr gets dlopen()'d and your once function needs to initialize a mutex or something that can only be properly done by a real threads library? Can we envision a scenario where that would be a problem? -- DE From deischen at freebsd.org Thu Nov 19 17:11:15 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Nov 19 17:11:21 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191206.40934.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> <200911191206.40934.jhb@freebsd.org> Message-ID: On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote: >> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >>> On Thu, 19 Nov 2009, John Baldwin wrote: >>> >>>> I would like to provide a pthread_once()-like facility in libc that library >>>> bits can use to initialize data safely rather than trying to home-roll their >>>> own variants (see the recent commit to stdtime in libc). Ideally what I >>>> would like to do is have libc use the "real" pthread_once() when libthr is >>>> linked in and fall back to a simple stub without libthr linked in. I know we >>>> already do something like this for _spinlock() and friends. My question is >>>> what is the most correct way to do this? Should libc grow a new _once() >>>> symbol ala _spinlock() that is a weak symbol to a stub version and >>>> pthread_once() in thr_once.c would override that, or should there be a >>>> _pthread_once() in libc that is a stub in place of the current stub_zero? I >>>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for >>>> backwards compat. Does this mean that for the future we would like to expose >>>> pthread symbols directly in libc? Meaning would we rather have libc export a >>>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock >>>> instead of _spinlock/unlock? >>> >>> pthread_once() is already a stub in libc that gets overloaded with the >>> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. >>> Isn't that what you want or does it not serve your purpose? >> >> Hmm, the libc stub will never run the init routine. I would like to do >> something like this: > > Perhaps this would work to fix pthread_once: No objection here. Still trying to figure out if that could potentially cause a problem with a dlopen()'d libthr. -- DE From jhb at freebsd.org Thu Nov 19 17:55:03 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 17:55:09 2009 Subject: Using pthread_once() in libc In-Reply-To: References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> Message-ID: <200911191254.50902.jhb@freebsd.org> On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: > On Thu, 19 Nov 2009, John Baldwin wrote: > > > On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > >> On Thu, 19 Nov 2009, John Baldwin wrote: > >> > >>> I would like to provide a pthread_once()-like facility in libc that library > >>> bits can use to initialize data safely rather than trying to home-roll their > >>> own variants (see the recent commit to stdtime in libc). Ideally what I > >>> would like to do is have libc use the "real" pthread_once() when libthr is > >>> linked in and fall back to a simple stub without libthr linked in. I know we > >>> already do something like this for _spinlock() and friends. My question is > >>> what is the most correct way to do this? Should libc grow a new _once() > >>> symbol ala _spinlock() that is a weak symbol to a stub version and > >>> pthread_once() in thr_once.c would override that, or should there be a > >>> _pthread_once() in libc that is a stub in place of the current stub_zero? I > >>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > >>> backwards compat. Does this mean that for the future we would like to expose > >>> pthread symbols directly in libc? Meaning would we rather have libc export a > >>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > >>> instead of _spinlock/unlock? > >> > >> pthread_once() is already a stub in libc that gets overloaded with the > >> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. > >> Isn't that what you want or does it not serve your purpose? > > > > Hmm, the libc stub will never run the init routine. I would like to do > > something like this: > > Well, I suppose you could do that. But what happens if libthr gets > dlopen()'d and your once function needs to initialize a mutex or > something that can only be properly done by a real threads library? > Can we envision a scenario where that would be a problem? Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for mutex lock/unlock as that avoids resolving the symbol until pthread_create() has been invoked? I guess then we could take an approach that works something like this: /* libc-internal function */ int _once(pthread_once_t *once_control, void (*init_routine)(void)) { if (__is_threaded) return (_pthread_once(once_control, init_routine)); return (_stub_once(once_control, init_routine)); } It is probably still a good idea to have the stub_once() patch I think so that pthread_once() DTRT in a single-threaded program. -- John Baldwin From deischen at freebsd.org Thu Nov 19 20:00:21 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Nov 19 20:00:27 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191254.50902.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <200911191202.30738.jhb@freebsd.org> <200911191254.50902.jhb@freebsd.org> Message-ID: On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: >> On Thu, 19 Nov 2009, John Baldwin wrote: >> >>> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >>>> On Thu, 19 Nov 2009, John Baldwin wrote: >>>> >>>>> I would like to provide a pthread_once()-like facility in libc that library >>>>> bits can use to initialize data safely rather than trying to home-roll their >>>>> own variants (see the recent commit to stdtime in libc). Ideally what I >>>>> would like to do is have libc use the "real" pthread_once() when libthr is >>>>> linked in and fall back to a simple stub without libthr linked in. I know we >>>>> already do something like this for _spinlock() and friends. My question is >>>>> what is the most correct way to do this? Should libc grow a new _once() >>>>> symbol ala _spinlock() that is a weak symbol to a stub version and >>>>> pthread_once() in thr_once.c would override that, or should there be a >>>>> _pthread_once() in libc that is a stub in place of the current stub_zero? I >>>>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for >>>>> backwards compat. Does this mean that for the future we would like to expose >>>>> pthread symbols directly in libc? Meaning would we rather have libc export a >>>>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock >>>>> instead of _spinlock/unlock? >>>> >>>> pthread_once() is already a stub in libc that gets overloaded with the >>>> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. >>>> Isn't that what you want or does it not serve your purpose? >>> >>> Hmm, the libc stub will never run the init routine. I would like to do >>> something like this: >> >> Well, I suppose you could do that. But what happens if libthr gets >> dlopen()'d and your once function needs to initialize a mutex or >> something that can only be properly done by a real threads library? >> Can we envision a scenario where that would be a problem? > > Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for > mutex lock/unlock as that avoids resolving the symbol until pthread_create() > has been invoked? I guess then we could take an approach that works > something like this: > > /* libc-internal function */ > int > _once(pthread_once_t *once_control, void (*init_routine)(void)) > { > > if (__is_threaded) > return (_pthread_once(once_control, init_routine)); > > return (_stub_once(once_control, init_routine)); > } > > It is probably still a good idea to have the stub_once() patch I think so > that pthread_once() DTRT in a single-threaded program. I guess that works. -- DE From jhb at freebsd.org Thu Nov 19 20:39:54 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 20:40:00 2009 Subject: Using pthread_once() in libc In-Reply-To: References: <200911191030.14151.jhb@freebsd.org> <200911191254.50902.jhb@freebsd.org> Message-ID: <200911191539.47588.jhb@freebsd.org> On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote: > On Thu, 19 Nov 2009, John Baldwin wrote: > > > On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote: > >> On Thu, 19 Nov 2009, John Baldwin wrote: > >> > >>> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: > >>>> On Thu, 19 Nov 2009, John Baldwin wrote: > >>>> > >>>>> I would like to provide a pthread_once()-like facility in libc that library > >>>>> bits can use to initialize data safely rather than trying to home-roll their > >>>>> own variants (see the recent commit to stdtime in libc). Ideally what I > >>>>> would like to do is have libc use the "real" pthread_once() when libthr is > >>>>> linked in and fall back to a simple stub without libthr linked in. I know we > >>>>> already do something like this for _spinlock() and friends. My question is > >>>>> what is the most correct way to do this? Should libc grow a new _once() > >>>>> symbol ala _spinlock() that is a weak symbol to a stub version and > >>>>> pthread_once() in thr_once.c would override that, or should there be a > >>>>> _pthread_once() in libc that is a stub in place of the current stub_zero? I > >>>>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for > >>>>> backwards compat. Does this mean that for the future we would like to expose > >>>>> pthread symbols directly in libc? Meaning would we rather have libc export a > >>>>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock > >>>>> instead of _spinlock/unlock? > >>>> > >>>> pthread_once() is already a stub in libc that gets overloaded with the > >>>> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. > >>>> Isn't that what you want or does it not serve your purpose? > >>> > >>> Hmm, the libc stub will never run the init routine. I would like to do > >>> something like this: > >> > >> Well, I suppose you could do that. But what happens if libthr gets > >> dlopen()'d and your once function needs to initialize a mutex or > >> something that can only be properly done by a real threads library? > >> Can we envision a scenario where that would be a problem? > > > > Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for > > mutex lock/unlock as that avoids resolving the symbol until pthread_create() > > has been invoked? I guess then we could take an approach that works > > something like this: > > > > /* libc-internal function */ > > int > > _once(pthread_once_t *once_control, void (*init_routine)(void)) > > { > > > > if (__is_threaded) > > return (_pthread_once(once_control, init_routine)); > > > > return (_stub_once(once_control, init_routine)); > > } > > > > It is probably still a good idea to have the stub_once() patch I think so > > that pthread_once() DTRT in a single-threaded program. > > I guess that works. Ok, after a few rounds with the compiler the attached patch actually finished a buildworld. Do you have any feedback on it? -- John Baldwin -------------- next part -------------- A non-text attachment was scrubbed... Name: stdtime.patch Type: text/x-diff Size: 4684 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20091119/b640be99/stdtime.bin From deischen at freebsd.org Thu Nov 19 21:02:08 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Nov 19 21:02:14 2009 Subject: Using pthread_once() in libc In-Reply-To: <200911191539.47588.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <200911191254.50902.jhb@freebsd.org> <200911191539.47588.jhb@freebsd.org> Message-ID: On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote: >> >> I guess that works. > > Ok, after a few rounds with the compiler the attached patch actually finished > a buildworld. Do you have any feedback on it? That looks fine to me :-) -- DE From bugmaster at FreeBSD.org Mon Nov 23 11:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 23 11:09:36 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200911231107.nANB75wC070271@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From ports at mcdermottroe.com Tue Nov 24 15:50:03 2009 From: ports at mcdermottroe.com (Conor McDermottroe) Date: Tue Nov 24 15:50:09 2009 Subject: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64 Message-ID: <200911241550.nAOFo3WM032896@freefall.freebsd.org> The following reply was made to PR threads/135673; it has been noted by GNATS. From: Conor McDermottroe To: bug-followup@FreeBSD.org, freebsd-bugs@desert.net Cc: Subject: Re: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64 Date: Tue, 24 Nov 2009 15:19:38 +0000 Thanks very much for the patch, we were running into it as well. The good news is that it improves the situation quite a bit. The bad news is that it does not appear to cure the problem entirely. Under heavy load we see the same problem re-occurring. We'll be bringing up another machine with 8.0 in the coming weeks and I hope to test it then. We're currently avoiding this bug by under-loading the 7.2 machine and handling more queries on a different 7.0 machine. Is there any information I can provide which would help diagnose this bug further? From attilio at freebsd.org Tue Nov 24 15:53:39 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Nov 24 15:53:45 2009 Subject: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64 In-Reply-To: <200911241550.nAOFo3WM032896@freefall.freebsd.org> References: <200911241550.nAOFo3WM032896@freefall.freebsd.org> Message-ID: <3bbf2fe10911240753i4fe41b74j760cbcd88a096b8d@mail.gmail.com> 2009/11/24 Conor McDermottroe : > The following reply was made to PR threads/135673; it has been noted by GNATS. > > From: Conor McDermottroe > To: bug-followup@FreeBSD.org, freebsd-bugs@desert.net > Cc: > Subject: Re: threads/135673: databases/mysql50-server - MySQL query > lock-ups on 7.2-RELEASE amd64 > Date: Tue, 24 Nov 2009 15:19:38 +0000 > > Thanks very much for the patch, we were running into it as well. The good > news is that it improves the situation quite a bit. The bad news is that > it does not appear to cure the problem entirely. Under heavy load we see > the same problem re-occurring. > > We'll be bringing up another machine with 8.0 in the coming weeks and I > hope to test it then. > > We're currently avoiding this bug by under-loading the 7.2 machine and > handling more queries on a different 7.0 machine. Is there any > information I can provide which would help diagnose this bug further? My last findings were revealing a sudden zeroing of userland structures where a lock was embedded, leaving some waiters on such locks stuck in the kernel. I think this is a MySQL bug and I feel to suggest you to upgrade to newest MySQL versions. Attilio -- Peace can only be achieved by understanding - A. Einstein