Date: Sat, 10 Mar 2007 01:50:13 +0100 (CET) From: Martin Blapp <mb@imp.ch> To: Julian Elischer <julian@elischer.org> Cc: Daniel Eischen <deischen@freebsd.org>, gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads Message-ID: <20070310014632.S6787@godot.imp.ch> In-Reply-To: <45F1FF03.80903@elischer.org> References: <200703091515.27133.tijl@ulyssis.org> <Pine.GSO.4.64.0703091215070.21532@sea.ntplx.net> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <45F1FF03.80903@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, >> But is it true for FreeBSD that 'ps -Hauxwww' should show all threads >> for a process with libc_r, libpthreads.so, or libthr.so ? > > Similarly for libpthread, it will show SOME threads but not as many as there > are threads in the process because only threads that are blocked > for IO in the kernel or are actually running at that instant will > show up. Threads that are not running or blocked in the kernel > are, once again just figments of the imagination of the process. > If you run a libpthread process with LIBPTHREAD_SCOPE_SYSTEM set to 'yes'. > then it will switch to 1:1 mode and there will be a kernel thread > instantiated for each thread in the process and yes you will see them in ps Ok, this explains why clamd with libpthreads with ps shows only some of the threads, and I suspected there was something like this. So I definitly need gdb to attach to a thread to look where it is blocked or what it is dooing ? The problem with gdb is that some of the threads are just doing one or two scans and then they disappear for ever. -- Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070310014632.S6787>