Date: Fri, 09 Mar 2007 16:53:30 -0800 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: Daniel Eischen <deischen@freebsd.org>, Martin Blapp <mb@imp.ch>, gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads Message-ID: <45F2018A.1090303@elischer.org> 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
Julian Elischer wrote: > Martin Blapp wrote: >> >> Hi, >> >>> There is no portable way to identify threads in another process. >>> There is also no guarantee that the tread is even externally visible. >>> Take >> >> But is it true for FreeBSD that 'ps -Hauxwww' should show all threads >> for a process with libc_r, libpthreads.so, or libthr.so ? > > no > > libc_r will only have one line in ps even if there are 10,000 threads > because they are an internal 'figment of the imagination of the process". > There is NO externally visible sign of them esxcept for the behaviour of > the process. (it does a lot of async operations). > > 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. Just to clarify, the threads that will show up in this case are: (1)threads blocked waiting for something in the kernel (e.g. I/O) plus (2)threads ACTUALLY RUNNING ON A CPU plus (3)any idle CPU workers for that process (i.e number of cpus - (2)) plus (4)a worker thread to catch and distribute signals. Any threads that are runnable but not yet allocated to a CPU worker or are waiting on some internal event (e.g. a pthread_mutex) will not show up, as the kernel doesn't know of their existence. numbers 2 and 3 are actually the same thing.. they are CPU workers but those in #2 are doing work for an internal thread and those in #3 are waiting to be assigned work (and are thus kind of in the same category as #1, waiting in the kernel to be woken up by a signal from within the process, to go get work to do when it is available. I don't know if this helps, but... > 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 -H. > libthr will always show all the threads because it is basically the > equivalent and optimised version of libpthread with > LIBPTHREAD_SCOPE_SYSTEM set. It only runs in that mode. > > >> >> -- >> Martin > > _______________________________________________ > 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?45F2018A.1090303>