From owner-freebsd-threads@FreeBSD.ORG Mon Mar 5 11:08:28 2007 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A54116A47B for ; Mon, 5 Mar 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9EC13C4C2 for ; Mon, 5 Mar 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l25B8SuO037636 for ; Mon, 5 Mar 2007 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l25B8RRx037632 for freebsd-threads@FreeBSD.org; Mon, 5 Mar 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2007 11:08:27 GMT Message-Id: <200703051108.l25B8RRx037632@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2007 11:08:28 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 9 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Mar 6 22:33:01 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58EAA16A403 for ; Tue, 6 Mar 2007 22:33:01 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 1722A13C467 for ; Tue, 6 Mar 2007 22:33:01 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix2-g20.free.fr (Postfix) with ESMTP id 774C2BDEA29 for ; Tue, 6 Mar 2007 22:09:26 +0100 (CET) Received: from graf.pompo.net (graf.pompo.net [81.56.186.139]) by smtp7-g19.free.fr (Postfix) with ESMTP id 8261F1523D for ; Tue, 6 Mar 2007 23:09:12 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id AB6001142C; Tue, 6 Mar 2007 23:09:06 +0100 (CET) Date: Tue, 6 Mar 2007 23:09:06 +0100 From: Thierry Thomas To: freebsd-threads@freebsd.org Message-ID: <20070306220906.GA96551@graf.pompo.net> Mail-Followup-To: freebsd-threads@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-STABLE i386 Organization: Kabbale Eros X-PGP: 0xC71405A2 Subject: ports/deskutils/pinot: yet another failure in pthread_testcancel X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2007 22:33:01 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I have just upgraded the port deskutils/pinot to the latest 0.70, and I have been testing the ten previous betas with the author: when the default /lib/libpthread.so.2 is used, both the GUI and the daemon core dump. A backtrace always reports things like: #5 0x28966e44 in pthread_mutexattr_init () from /lib/libpthread.so.2 #6 0x00000001 in ?? () #7 0x0813240c in ?? () #8 0xbfbfdef8 in ?? () #9 0x28964e91 in pthread_mutex_lock () from /lib/libpthread.so.2 Previous frame inner to this frame (corrupt stack?) #0 0x2896f1eb in pthread_testcancel () from /lib/libpthread.so.2 When /etc/libmap.conf is set to replace libpthread by libc_r, everything runs OK. How to reproduce the problem: - cvsup your ports tree; - cd /usr/ports/deskutils/pinot - make [or make -DWITH_DEBUG] - sudo make install [-DWITH_DEBUG] - rm -rf ~/.pinot - pinot& - when a window opens, choose your $HOME and valid =3D> this launches pinot-dbus-daemon, which should try to index your files - with libpthread, you'll find the core file in ~/.pinot I'm not a threads guru, and I cannot say if this is a bug in libpthread or some bad calls in pinot; any expert to check this? Thanks. --=20 Th. Thomas. --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF7eaCc95pjMcUBaIRAh5SAKDq89j2hfoHF5kh4jBM7MiQwZRlvQCg55NU XgsaQFSuFbCvi9AVGOYcI1c= =/zVq -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-threads@FreeBSD.ORG Fri Mar 9 14:47:49 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87A2916A400 for ; Fri, 9 Mar 2007 14:47:49 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from nibbel.kulnet.kuleuven.ac.be (nibbel.kulnet.kuleuven.ac.be [134.58.240.41]) by mx1.freebsd.org (Postfix) with ESMTP id 3F02E13C491 for ; Fri, 9 Mar 2007 14:47:49 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 07F714D5EC for ; Fri, 9 Mar 2007 15:15:30 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 486324D5D7 for ; Fri, 9 Mar 2007 15:15:29 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id 1F0E12CAAE5 for ; Fri, 9 Mar 2007 15:15:29 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l29EFSJk002546 for ; Fri, 9 Mar 2007 15:15:28 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-threads@freebsd.org Date: Fri, 9 Mar 2007 15:15:25 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703091515.27133.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Subject: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 14:47:49 -0000 Is it somehow possible to send a signal to a specific thread in another process similar to the linux tkill and tgkill syscalls? I've seen the thr_kill call that takes an lwpid as argument, but it can't send a signal to another process can it? From owner-freebsd-threads@FreeBSD.ORG Fri Mar 9 17:18:22 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF83B16A403 for ; Fri, 9 Mar 2007 17:18:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A4DEA13C49D for ; Fri, 9 Mar 2007 17:18:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l29HILxj013538; Fri, 9 Mar 2007 12:18:21 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 09 Mar 2007 12:18:21 -0500 (EST) Date: Fri, 9 Mar 2007 12:18:21 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Tijl Coosemans In-Reply-To: <200703091515.27133.tijl@ulyssis.org> Message-ID: References: <200703091515.27133.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 17:18:23 -0000 On Fri, 9 Mar 2007, Tijl Coosemans wrote: > Is it somehow possible to send a signal to a specific thread in > another process similar to the linux tkill and tgkill syscalls? > > I've seen the thr_kill call that takes an lwpid as argument, but it > can't send a signal to another process can it? No, it is not possible and it shouldn't be possible as it's not portable. From outside the process, you can send a signal to another _process_ (which will be delivered to one of its threads depending on their signal masks), but not to a specific thread in another process. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Mar 9 20:00:18 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28D7416A412; Fri, 9 Mar 2007 20:00:18 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from rusty.kulnet.kuleuven.ac.be (rusty.kulnet.kuleuven.ac.be [134.58.240.42]) by mx1.freebsd.org (Postfix) with ESMTP id D741413C4A7; Fri, 9 Mar 2007 20:00:17 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 039EC1D78A7; Fri, 9 Mar 2007 21:00:17 +0100 (CET) Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be [134.58.240.72]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id DFE101D7607; Fri, 9 Mar 2007 21:00:15 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtp02.kuleuven.be (Postfix) with ESMTP id 16ED92CAB1E; Fri, 9 Mar 2007 21:00:13 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l29K0Cat003258; Fri, 9 Mar 2007 21:00:12 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-threads@freebsd.org Date: Fri, 9 Mar 2007 21:00:08 +0100 User-Agent: KMail/1.9.5 References: <200703091515.27133.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703092100.12199.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Daniel Eischen , gerald@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 20:00:18 -0000 On Friday 09 March 2007 18:18, Daniel Eischen wrote: > On Fri, 9 Mar 2007, Tijl Coosemans wrote: > > Is it somehow possible to send a signal to a specific thread in > > another process similar to the linux tkill and tgkill syscalls? > > > > I've seen the thr_kill call that takes an lwpid as argument, but > > it can't send a signal to another process can it? > > No, it is not possible and it shouldn't be possible > as it's not portable. From outside the process, you > can send a signal to another _process_ (which will > be delivered to one of its threads depending on > their signal masks), but not to a specific thread > in another process. Ok, thanks. The reason I asked is because Wine uses this to let the wineserver process (windows kernel) send signals to threads in a wine process. The only solution I see then is to have some sort of service thread in the receiving process to dispatch the signal. That would be a portable solution, but lots of work... From owner-freebsd-threads@FreeBSD.ORG Fri Mar 9 22:30:25 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E2D516A404 for ; Fri, 9 Mar 2007 22:30:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6935813C4B3 for ; Fri, 9 Mar 2007 22:30:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 09 Mar 2007 14:03:56 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 490DD125C89; Fri, 9 Mar 2007 14:19:21 -0800 (PST) Message-ID: <45F1DD68.8040103@elischer.org> Date: Fri, 09 Mar 2007 14:19:20 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tijl Coosemans References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> In-Reply-To: <200703092100.12199.tijl@ulyssis.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 22:30:25 -0000 Tijl Coosemans wrote: > On Friday 09 March 2007 18:18, Daniel Eischen wrote: >> On Fri, 9 Mar 2007, Tijl Coosemans wrote: >>> Is it somehow possible to send a signal to a specific thread in >>> another process similar to the linux tkill and tgkill syscalls? >>> >>> I've seen the thr_kill call that takes an lwpid as argument, but >>> it can't send a signal to another process can it? >> No, it is not possible and it shouldn't be possible >> as it's not portable. From outside the process, you >> can send a signal to another _process_ (which will >> be delivered to one of its threads depending on >> their signal masks), but not to a specific thread >> in another process. > > Ok, thanks. The reason I asked is because Wine uses this to let the > wineserver process (windows kernel) send signals to threads in a wine > process. > > The only solution I see then is to have some sort of service thread in > the receiving process to dispatch the signal. That would be a portable > solution, but lots of work... How does something external to a process identify a thread within the process? And even if you could tell the threads appart, ho do you know which one to signal? There is no portable way to identify threads in another process. There is also no guarantee that the tread is even externally visible. Take the example of a multiplexed threading library (such as libc_r) which multiplexes all the threads onto a single user process/thread. you basiclly HAVE to ask an agent within the process to signal the right thread for you on such a system. If they are doing things like that then they are basically writing for only Linux. > _______________________________________________ > 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" From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 00:32:35 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 028EE16A400; Sat, 10 Mar 2007 00:32:35 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7CD2B13C4B2; Sat, 10 Mar 2007 00:32:33 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l2A0WQex004715; Sat, 10 Mar 2007 01:32:27 +0100 (CET) (envelope-from mb@imp.ch) Date: Sat, 10 Mar 2007 01:32:26 +0100 (CET) From: Martin Blapp To: Julian Elischer In-Reply-To: <45F1DD68.8040103@elischer.org> Message-ID: <20070310012921.I6787@godot.imp.ch> References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 00:32:35 -0000 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 ? -- Martin From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 00:42:46 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ADFE16A401 for ; Sat, 10 Mar 2007 00:42:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8266013C481 for ; Sat, 10 Mar 2007 00:42:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 09 Mar 2007 16:16:15 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 6A589125B11; Fri, 9 Mar 2007 16:42:43 -0800 (PST) Message-ID: <45F1FF03.80903@elischer.org> Date: Fri, 09 Mar 2007 16:42:43 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Martin Blapp References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> In-Reply-To: <20070310012921.I6787@godot.imp.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 00:42:46 -0000 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. 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 From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 00:50:20 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC60D16A400; Sat, 10 Mar 2007 00:50:20 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA1D13C471; Sat, 10 Mar 2007 00:50:19 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l2A0oDTp022668; Sat, 10 Mar 2007 01:50:14 +0100 (CET) (envelope-from mb@imp.ch) Date: Sat, 10 Mar 2007 01:50:13 +0100 (CET) From: Martin Blapp To: Julian Elischer In-Reply-To: <45F1FF03.80903@elischer.org> Message-ID: <20070310014632.S6787@godot.imp.ch> References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <45F1FF03.80903@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 00:50:20 -0000 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 From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 00:53:32 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4F4516A498 for ; Sat, 10 Mar 2007 00:53:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id AC4B313C4BA for ; Sat, 10 Mar 2007 00:53:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 09 Mar 2007 16:27:02 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 97ECD125B51; Fri, 9 Mar 2007 16:53:30 -0800 (PST) Message-ID: <45F2018A.1090303@elischer.org> Date: Fri, 09 Mar 2007 16:53:30 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Julian Elischer References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <45F1FF03.80903@elischer.org> In-Reply-To: <45F1FF03.80903@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Martin Blapp , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 00:53:32 -0000 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" From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 11:31:20 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C329816A400; Sat, 10 Mar 2007 11:31:20 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.freebsd.org (Postfix) with ESMTP id 534CC13C467; Sat, 10 Mar 2007 11:31:20 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 3487A138223; Sat, 10 Mar 2007 12:31:19 +0100 (CET) Received: from smtps01 (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 3AC211381E8; Sat, 10 Mar 2007 12:31:18 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [10.4.16.222]) by smtps01 (Postfix) with ESMTP id 064E82E68CB; Sat, 10 Mar 2007 12:31:18 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.8/8.13.8) with ESMTP id l2ABVHDj001879; Sat, 10 Mar 2007 12:31:17 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-threads@freebsd.org Date: Sat, 10 Mar 2007 12:31:11 +0100 User-Agent: KMail/1.9.5 References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> In-Reply-To: <45F1DD68.8040103@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703101231.16407.tijl@ulyssis.org> X-Virus-Scanned: by KULeuven Antivirus Cluster Cc: Daniel Eischen , gerald@freebsd.org, Julian Elischer Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 11:31:20 -0000 On Friday 09 March 2007 23:19, Julian Elischer wrote: > Tijl Coosemans wrote: >> On Friday 09 March 2007 18:18, Daniel Eischen wrote: >>> On Fri, 9 Mar 2007, Tijl Coosemans wrote: >>>> Is it somehow possible to send a signal to a specific thread in >>>> another process similar to the linux tkill and tgkill syscalls? >>>> >>>> I've seen the thr_kill call that takes an lwpid as argument, but >>>> it can't send a signal to another process can it? >>> >>> No, it is not possible and it shouldn't be possible >>> as it's not portable. From outside the process, you >>> can send a signal to another _process_ (which will >>> be delivered to one of its threads depending on >>> their signal masks), but not to a specific thread >>> in another process. >> >> Ok, thanks. The reason I asked is because Wine uses this to let the >> wineserver process (windows kernel) send signals to threads in a >> wine process. >> >> The only solution I see then is to have some sort of service thread >> in the receiving process to dispatch the signal. That would be a >> portable solution, but lots of work... > > How does something external to a process identify a thread within > the process? Wineserver plays the role of the windows kernel (more or less). It knows about all the (win32) threads in every wine process. Whenever a wine process creates a new thread it sends the thread id to the wineserver. On FreeBSD this is currently always -1. On Linux it is obtained with gettid(). This id is then later used with tgkill(). > And even if you could tell the threads appart, ho do you know which > one to signal? Wineserver handles IPC calls (read: syscalls) from wine processes. An example where wineserver sends a signal to a specific threads is when some thread requests to suspend another thread. > There is no portable way to identify threads in another process. > There is also no guarantee that the tread is even externally > visible. Take the example of a multiplexed threading library (such > as libc_r) which multiplexes all the threads onto a single user > process/thread. you basiclly HAVE to ask an agent within the process > to signal the right thread for you on such a system. If they are > doing things like that then they are basically writing for only > Linux. So, in case of wineserver and wine, the (only?) portable way would be for wineserver to know all the pthread_self() identifiers, which can then be used in an IPC call to an agent in the wine process, that in turn uses pthread_kill()? From owner-freebsd-threads@FreeBSD.ORG Sat Mar 10 15:15:34 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D749C16A407 for ; Sat, 10 Mar 2007 15:15:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id A245113C46B for ; Sat, 10 Mar 2007 15:15:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 10 Mar 2007 06:48:59 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7D14F125B84; Sat, 10 Mar 2007 07:15:32 -0800 (PST) Message-ID: <45F2CB94.6070805@elischer.org> Date: Sat, 10 Mar 2007 07:15:32 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tijl Coosemans References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <200703101231.16407.tijl@ulyssis.org> In-Reply-To: <200703101231.16407.tijl@ulyssis.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2007 15:15:35 -0000 Tijl Coosemans wrote: > On Friday 09 March 2007 23:19, Julian Elischer wrote: >> Tijl Coosemans wrote: >>> On Friday 09 March 2007 18:18, Daniel Eischen wrote: >>>> On Fri, 9 Mar 2007, Tijl Coosemans wrote: >>>>> Is it somehow possible to send a signal to a specific thread in >>>>> another process similar to the linux tkill and tgkill syscalls? >>>>> >>>>> I've seen the thr_kill call that takes an lwpid as argument, but >>>>> it can't send a signal to another process can it? >>>> No, it is not possible and it shouldn't be possible >>>> as it's not portable. From outside the process, you >>>> can send a signal to another _process_ (which will >>>> be delivered to one of its threads depending on >>>> their signal masks), but not to a specific thread >>>> in another process. >>> Ok, thanks. The reason I asked is because Wine uses this to let the >>> wineserver process (windows kernel) send signals to threads in a >>> wine process. >>> >>> The only solution I see then is to have some sort of service thread >>> in the receiving process to dispatch the signal. That would be a >>> portable solution, but lots of work... >> How does something external to a process identify a thread within >> the process? > > Wineserver plays the role of the windows kernel (more or less). It > knows about all the (win32) threads in every wine process. Whenever > a wine process creates a new thread it sends the thread id to the > wineserver. On FreeBSD this is currently always -1. On Linux it is > obtained with gettid(). This id is then later used with tgkill(). > >> And even if you could tell the threads appart, ho do you know which >> one to signal? > > Wineserver handles IPC calls (read: syscalls) from wine processes. > An example where wineserver sends a signal to a specific threads is > when some thread requests to suspend another thread. > >> There is no portable way to identify threads in another process. >> There is also no guarantee that the tread is even externally >> visible. Take the example of a multiplexed threading library (such >> as libc_r) which multiplexes all the threads onto a single user >> process/thread. you basiclly HAVE to ask an agent within the process >> to signal the right thread for you on such a system. If they are >> doing things like that then they are basically writing for only >> Linux. > > So, in case of wineserver and wine, the (only?) portable way would be > for wineserver to know all the pthread_self() identifiers, which can > then be used in an IPC call to an agent in the wine process, that in > turn uses pthread_kill()? basically that would, at least be portable. It would be possible to do it (siggnal it directly) in libpthread if it were running in system_scope mode, (libprhtread can run in 2 modes) and it would be possible to do it if you linked with libthr too though I don't knwo all the details.