From owner-freebsd-threads@FreeBSD.ORG Sun Jun 22 16:35:27 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D29637B401 for ; Sun, 22 Jun 2003 16:35:27 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8269843FB1 for ; Sun, 22 Jun 2003 16:35:26 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5MNZKXh028805; Sun, 22 Jun 2003 19:35:20 -0400 (EDT) Date: Sun, 22 Jun 2003 19:35:20 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2003 23:35:27 -0000 On Fri, 20 Jun 2003, Julian Elischer wrote: > > On Fri, 20 Jun 2003, Igor Sysoev wrote: > > > > > We can implement such scheme on x86: > > > > gs -> [ TP ] ---> [ TLS ] > > [ struct kse_mailbox ] +-> [ struct kse_thr_mailbox ] > > [ .km_curthread ] -+ > > > > When UTS would switch to the next thread it should set thread's TLS: > > > > kse_mailbox.km_curthread = NULL; > > gs:[0] = next_thr_tls; > > kse_mailbox.km_curthread = next_kse_thr_mailbox; > > yes and the last line is atomic.. But remember having a NULL curhtread > pointer stops upcalls but it is not the ONLY thing that stops upcalls.. > A flag TMF_NOUPCALLS (spelling?) in the mailbox will also inhibit any > upcalls. 1:1 threads (BOUND) threads, (system scope threads?) set this > bit, but they still can have a mailbox for other purposes. (e.g. setting > mode flags and stuff). Yes, but we don't always have a current thread, so this method doesn't work for all cases. > If you are talking about libthr when you say 1:1 then they > have gs:0 pointing to an array of pointers each of which points to > a thread structure.. (they have the same indirection, but there is no > KSE mailbox at teh indirection point, just the pointer.) > > (in _setcurthread.c ) > void *ldt_entries[MAXTHR]; > (these are set to point to thread structures as they are needed > and %gs:0 points to an entry in this array) > > There is a small race we must guard against when accessing TLS.. > > %gs-->KSE--->TLS > > however the thread can be preemted between any two machine instructions, > and unless the TMF_NOUPCALLS bit is set, it may start executing again > under a DIFFERENT KSE. > > this means that we can not do: > > lea gs:0, %esi > movl (%esi),%esi > > to find the TLS as at teh time of the 2nd command, we may have been > pre-empted and %gs may point to a different place.. > > HOWEVER ensuring that we get past teh gs and into the actual > thread-specific stuff in one instruction, > > e.g. > > movl gs:0, %esi ;%esi now points to a thread-specific thing.. > > should get around this.. Since libpthread doesn't always have a current thread, we can't rely on this. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 22 23:16:42 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC7437B401 for ; Sun, 22 Jun 2003 23:16:42 -0700 (PDT) Received: from sccrmhc11.attbi.com (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A82843FAF for ; Sun, 22 Jun 2003 23:16:41 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc11) with ESMTP id <2003062306164001100454sce>; Mon, 23 Jun 2003 06:16:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA79701; Sun, 22 Jun 2003 23:16:39 -0700 (PDT) Date: Sun, 22 Jun 2003 23:16:38 -0700 (PDT) From: Julian Elischer To: Igor Sysoev In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 06:16:42 -0000 On Sat, 21 Jun 2003, Igor Sysoev wrote: > On Fri, 20 Jun 2003, Julian Elischer wrote: > > > > We can implement such scheme on x86: > > > > > > gs -> [ TP ] ---> [ TLS ] > > > [ struct kse_mailbox ] +-> [ struct kse_thr_mailbox ] > > > [ .km_curthread ] -+ > > > > > > When UTS would switch to the next thread it should set thread's TLS: > > > > > > kse_mailbox.km_curthread = NULL; > > > gs:[0] = next_thr_tls; > > > kse_mailbox.km_curthread = next_kse_thr_mailbox; > > > > yes and the last line is atomic.. But remember having a NULL curhtread > > pointer stops upcalls but it is not the ONLY thing that stops upcalls.. > > A flag TMF_NOUPCALLS (spelling?) in the mailbox will also inhibit any > > upcalls. 1:1 threads (BOUND) threads, (system scope threads?) set this > > bit, but they still can have a mailbox for other purposes. (e.g. setting > > mode flags and stuff). > > So NULL curthread is the short term (in UTS only) and atomic method to > disable upcalls while KMF_NOUPCALL flag is the long term and non-atomic (we > can not atomically update bit masks in general) method ? exactly. > > > Igor Sysoev > http://sysoev.ru/en/ > > > From owner-freebsd-threads@FreeBSD.ORG Sun Jun 22 23:26:16 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC0737B401; Sun, 22 Jun 2003 23:26:16 -0700 (PDT) Received: from rwcrmhc11.attbi.com (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC7C43FB1; Sun, 22 Jun 2003 23:26:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <20030623062615013008t91ie>; Mon, 23 Jun 2003 06:26:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA79778; Sun, 22 Jun 2003 23:26:14 -0700 (PDT) Date: Sun, 22 Jun 2003 23:26:13 -0700 (PDT) From: Julian Elischer To: deischen@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 06:26:16 -0000 On Sun, 22 Jun 2003, Daniel Eischen wrote: > On Fri, 20 Jun 2003, Julian Elischer wrote: > > > > On Fri, 20 Jun 2003, Igor Sysoev wrote: > > > > > > > > We can implement such scheme on x86: > > > > > > gs -> [ TP ] ---> [ TLS ] > > > [ struct kse_mailbox ] +-> [ struct kse_thr_mailbox ] > > > [ .km_curthread ] -+ > > > > > > When UTS would switch to the next thread it should set thread's TLS: > > > > > > kse_mailbox.km_curthread = NULL; > > > gs:[0] = next_thr_tls; > > > kse_mailbox.km_curthread = next_kse_thr_mailbox; > > > > yes and the last line is atomic.. But remember having a NULL curhtread > > pointer stops upcalls but it is not the ONLY thing that stops upcalls.. > > A flag TMF_NOUPCALLS (spelling?) in the mailbox will also inhibit any > > upcalls. 1:1 threads (BOUND) threads, (system scope threads?) set this > > bit, but they still can have a mailbox for other purposes. (e.g. setting > > mode flags and stuff). > > Yes, but we don't always have a current thread, so this method > doesn't work for all cases. Firstly, I think that all threads should HAVE mailboxen, even if we don't use them. If we are running in the UTS or the initial 'thread' before getting a 'kse' then it would be an error to access TLS. Do you disagree? > > > If you are talking about libthr when you say 1:1 then they > > have gs:0 pointing to an array of pointers each of which points to > > a thread structure.. (they have the same indirection, but there is no > > KSE mailbox at teh indirection point, just the pointer.) > > > > (in _setcurthread.c ) > > void *ldt_entries[MAXTHR]; > > (these are set to point to thread structures as they are needed > > and %gs:0 points to an entry in this array) > > > > There is a small race we must guard against when accessing TLS.. > > > > %gs-->KSE--->TLS > > > > however the thread can be preemted between any two machine instructions, > > and unless the TMF_NOUPCALLS bit is set, it may start executing again > > under a DIFFERENT KSE. > > > > this means that we can not do: > > > > lea gs:0, %esi > > movl (%esi),%esi > > > > to find the TLS as at teh time of the 2nd command, we may have been > > pre-empted and %gs may point to a different place.. > > > > HOWEVER ensuring that we get past teh gs and into the actual > > thread-specific stuff in one instruction, > > > > e.g. > > > > movl gs:0, %esi ;%esi now points to a thread-specific thing.. > > > > should get around this.. > > Since libpthread doesn't always have a current thread, we can't rely > on this. I think we should say that if there is no current thread there is no Thread -specific data.... > > -- > Dan Eischen > > From owner-freebsd-threads@FreeBSD.ORG Mon Jun 23 05:28:52 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68AA737B401 for ; Mon, 23 Jun 2003 05:28:52 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3AE243FCB for ; Mon, 23 Jun 2003 05:28:51 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5NCSiXh011924; Mon, 23 Jun 2003 08:28:47 -0400 (EDT) Date: Mon, 23 Jun 2003 08:28:44 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 12:28:52 -0000 On Sun, 22 Jun 2003, Julian Elischer wrote: > On Sun, 22 Jun 2003, Daniel Eischen wrote: > > > On Fri, 20 Jun 2003, Julian Elischer wrote: > > > > > > On Fri, 20 Jun 2003, Igor Sysoev wrote: > > > > > > > > > > > We can implement such scheme on x86: > > > > > > > > gs -> [ TP ] ---> [ TLS ] > > > > [ struct kse_mailbox ] +-> [ struct kse_thr_mailbox ] > > > > [ .km_curthread ] -+ > > > > > > > > When UTS would switch to the next thread it should set thread's TLS: > > > > > > > > kse_mailbox.km_curthread = NULL; > > > > gs:[0] = next_thr_tls; > > > > kse_mailbox.km_curthread = next_kse_thr_mailbox; > > > > > > yes and the last line is atomic.. But remember having a NULL curhtread > > > pointer stops upcalls but it is not the ONLY thing that stops upcalls.. > > > A flag TMF_NOUPCALLS (spelling?) in the mailbox will also inhibit any > > > upcalls. 1:1 threads (BOUND) threads, (system scope threads?) set this > > > bit, but they still can have a mailbox for other purposes. (e.g. setting > > > mode flags and stuff). > > > > Yes, but we don't always have a current thread, so this method > > doesn't work for all cases. > > Firstly, I think that all threads should HAVE mailboxen, even if we > don't use them. If we are running in the UTS or the initial > 'thread' before getting a 'kse' then it would be an error to access TLS. > > Do you disagree? Nope :-) > > > If you are talking about libthr when you say 1:1 then they > > > have gs:0 pointing to an array of pointers each of which points to > > > a thread structure.. (they have the same indirection, but there is no > > > KSE mailbox at teh indirection point, just the pointer.) > > > > > > (in _setcurthread.c ) > > > void *ldt_entries[MAXTHR]; > > > (these are set to point to thread structures as they are needed > > > and %gs:0 points to an entry in this array) > > > > > > There is a small race we must guard against when accessing TLS.. > > > > > > %gs-->KSE--->TLS > > > > > > however the thread can be preemted between any two machine instructions, > > > and unless the TMF_NOUPCALLS bit is set, it may start executing again > > > under a DIFFERENT KSE. > > > > > > this means that we can not do: > > > > > > lea gs:0, %esi > > > movl (%esi),%esi > > > > > > to find the TLS as at teh time of the 2nd command, we may have been > > > pre-empted and %gs may point to a different place.. > > > > > > HOWEVER ensuring that we get past teh gs and into the actual > > > thread-specific stuff in one instruction, > > > > > > e.g. > > > > > > movl gs:0, %esi ;%esi now points to a thread-specific thing.. > > > > > > should get around this.. > > > > Since libpthread doesn't always have a current thread, we can't rely > > on this. > > I think we should say that if there is no current thread there is no > Thread -specific data.... Right. It just forces libpthread to differentiate between critical regions when there is a thread and when there isn't. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 23 08:06:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA97D37B401 for ; Mon, 23 Jun 2003 08:06:31 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3018943FE0 for ; Mon, 23 Jun 2003 08:06:30 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id C159F5482B; Mon, 23 Jun 2003 10:06:27 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 61A746D452; Mon, 23 Jun 2003 10:06:27 -0500 (CDT) Date: Mon, 23 Jun 2003 10:06:27 -0500 From: "Jacques A. Vidrine" To: Mike Makonnen Message-ID: <20030623150627.GD82167@madman.celabo.org> References: <20030618210812.GB21622@rot13.obsecurity.org> <20030619055933.FNBD4805.out003.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030619055933.FNBD4805.out003.verizon.net@kokeb.ambesa.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: threads@FreeBSD.org cc: kris@obsecurity.org Subject: Re: making nsswitch(3) thread-safe (was Re: Removal of bogus gethostbyaddr_r()) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 15:06:32 -0000 [Sorry for the late reply. As you may or may not have noticed :-) my FreeBSD hiatus continues :-( I'll be back, just not sure when yet.] On Thu, Jun 19, 2003 at 01:59:32AM -0400, Mike Makonnen wrote: > > [ Jacques, I'm CC'ing you since this affects nss ] Thanks, Mike! -- for CC'ing me and for looking at this in the first place. > I just took a look into what it would take to make the gethostby*_r functions > thread safe, and it isn't pretty. The "thread-unsafeness" goes all the way > down into the individual methods for the various nsswitch(3) databases (dns, > files, etc). So, the most expedient and least invasive way to go about it would > be to put a mutex in the gethostby* functions that is dependent on __isthreaded > being true. This, offcourse, means that the entire call-chain (from top to > bottom) is locked for the duration of a call to one of these functions, which > can be a considerable amount of time if it has to timeout. During this time no > other thread in the application can resolve a host because it will be blocked on > said mutex. You couldn't take this approach even if you wanted. No part of libc should hold a lock while making calls through nsdispatch. NSS modules are free to call back into libc. Imagine holding a lock in gethostbyname_r, calling through nsdispatch and getting to, say, the LDAP backend. The LDAP backend might itself invoke gethostbyname_r or some other nsdispatch consumer resulting in recursive locking or lock order reversals. > To my mind the way to fix this properly is to make the nsdispatch(3) > call-chain in libc thread-safe from the ground-up. This is a huge task in and of > itself, but is complicated even further by the fact that whatever we do can't > change the semantics of the existing user-visible functions. Yes, this is the approach that must be taken. The nsdispatch engine is itself thread-safe. The getpw*_r, getgr*_r functions are thread-safe. I believe that with the exception of the `dns' backend, the existing backends are thread-safe. > I think there are three points to keep in mind: > > 1. The nsswitch(3) database functions should be made thread-safe, but at the > same time not change the thread-unsafe semantics that third-party apps > might expect (through nsdispatch(3)). > 2. The thread-unsafeness starts at the bottom (low-level functions) of the > call-chain, in the nsswitch(3) database functions. > 3. Because so many databases (hosts, passwd, group, etc) will be affected by > this it would be too huge a task to do it all at once. The safest approach > is probably to introduce the changes separately a few at a time. What do you mean by the `nsswitch(3) database functions' ? Do you mean the backends? If so, yes, the backends must ultimately be thread-safe, and it is best to manage them one database at a time i.e., all built-in backends --- files, nis, dns --- for a database must be done at once. > We can achieve this by > Introducing a variable that gets passed down the call-chain telling the > nsswitch(3) database functions whether the "destination address" (return > value) will by allocated by the caller or not. If this variable is false then > the routines can use a static buffer, otherwise, they will assume the caller has > allocated the necessary space. > > Most of the functions will need a lot more work than this to make them > fully thread-safe. The advantage of doing it this way is that it maintains > the status-quo while allowing us to make the individual subsystems > thread-safe separately and as time and resources permit. > > The following patch shows what I have in mind. It won't > compile just yet, but it might make what I'm saying a little clearer :-) > This initial phase is really just a mechanical change of argument lists. It > doesn't introduce any thread-safeness on its own. It just makes it easier to > introduce such changes safely on a subsytem by subsystem basis. > > Basically, the _nsdispatch() functionality is moved into nsdispatch_common(), > which takes a va_list as its last argument instead of a variable number of > arguments. It also takes one additional argument(int is_r) so callers can tell > it what kind of semantics they want. Applications calling nsdispatch() get a > wrapper that passes a false (0) value in the is_r argument. Callers from within > libc will continue calling_nsdispatch(), which also grows an additional argument > (int is_r) that callers can pass down to the nsswitch(3) database functions > through nsdispatch_common(). > > What do you think? Should I continue with this or do you think it's bogus? > > The important point to keep in mind is that we have to keep the dual semantics > (thread-safe and unsafe) all the way down the call-chain because only the > top-level and low-level functions know the actual memory type and size that > needs to be allocated for the return value to the library users. So, we can't > make the low-level nsswitch(2) database functions unconditionally thread-safe > and restrict the dual semantics to the top-level functions. I think this is bogus :-) I must say I don't really understand what you are trying to accomplish ... maybe we should get on IRC and chat. Also, please look at getpwent.c to see how thread-safe versus non-thread-safe entry points to getpw* are handled if you have not already. I can't see any need to add this `is_r' argument. I don't see the purpose of it. The hardest part of making the thread-safe gethost*_r functions, IMHO (after having done some work in this area) is untangling the KAME-contributed code. There is a lot of incest between the implementations of the various high-level resolver routines (gethostbyname, getaddrinfo, getipnodebyname, etc.) that complicates things. But the approach is conceptually simple: 1. Write gethostbyname_r (thread-safe), which invokes nsdispatch("gethostbyname_r", ...). 2. Make each back-end thread-safe. Starting with a global lock is reasonable. I don't think we can ever do anything efficient with the BIND 4 resolver, anyway. Only I think you want to do the whole family of functions in one blow, not one-at-a-time. (But maybe I'm wrong here, 'cause that has certainly kept me from committing any partial work in this area.) Note also that the libc<-->NSS modules interface is constrained. Nominally we use the GNU libc interface, which has different entry points for e.g. gethostbyname and gethostbyname_r, with a set number and type of parameters. We don't want to change these interface lest we make porting NSS modules to FreeBSD harder. We can add some interfaces, though, where needed (i.e. getaddrinfo). You can contact me in a number of ways to discuss: - EFnet nickname `nectar' (or whatever nick shows up for `nectar@free.bsd') - AIM `nectar5' - ICQ `17783107' - Yahoo! `nectar' - MSN `nectar523@hotmail.com' - Voice 612-743-3364 It would be best if we could `schedule' something. I apologize, but my freetime is very slim lately. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 00:15:40 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5014337B401 for ; Wed, 25 Jun 2003 00:15:40 -0700 (PDT) Received: from hotmail.com (law9-f105.law9.hotmail.com [64.4.9.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E4944001 for ; Wed, 25 Jun 2003 00:15:39 -0700 (PDT) (envelope-from chaudharyanurag@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jun 2003 00:15:39 -0700 Received: from 202.144.62.166 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 25 Jun 2003 07:15:39 GMT X-Originating-IP: [202.144.62.166] X-Originating-Email: [chaudharyanurag@hotmail.com] From: "Anurag Chaudhary" To: freebsd-threads@freebsd.org Date: Wed, 25 Jun 2003 12:45:39 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jun 2003 07:15:39.0868 (UTC) FILETIME=[9508D1C0:01C33AE9] Subject: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 07:15:40 -0000 hi I am having a multi-threaded application. the child thread has to wait on a semaphore but when it does so the parent thread stops responding and taking inputs from the keyboard. I tried changing the scheduling policy and priority of the child thread but in vain. child thread is created with default attributes. Can anybody figure out some solution for this? urgent help required thanx Chaudhary Anurag _________________________________________________________________ Take this online tour. Win an HCL Beanstalk PC. http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 00:33:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C7737B401 for ; Wed, 25 Jun 2003 00:33:04 -0700 (PDT) Received: from sccrmhc13.attbi.com (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D92B43FBD for ; Wed, 25 Jun 2003 00:33:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc13) with ESMTP id <20030625073303016000q4vpe>; Wed, 25 Jun 2003 07:33:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA98522; Wed, 25 Jun 2003 00:33:02 -0700 (PDT) Date: Wed, 25 Jun 2003 00:33:02 -0700 (PDT) From: Julian Elischer To: Anurag Chaudhary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 07:33:05 -0000 Which thread library are you using? And on what release of the OS? On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > hi > > I am having a multi-threaded application. the child thread has to wait on a > semaphore but when it does so the parent thread stops responding and taking > inputs from the keyboard. > I tried changing the scheduling policy and priority of the child thread but > in vain. > child thread is created with default attributes. > Can anybody figure out some solution for this? > > urgent help required > > thanx > Chaudhary Anurag > > _________________________________________________________________ > Take this online tour. Win an HCL Beanstalk PC. > http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html > > _______________________________________________ > 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 Wed Jun 25 00:35:42 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0854937B401 for ; Wed, 25 Jun 2003 00:35:42 -0700 (PDT) Received: from hotmail.com (law9-f37.law9.hotmail.com [64.4.9.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A63F44005 for ; Wed, 25 Jun 2003 00:35:41 -0700 (PDT) (envelope-from chaudharyanurag@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jun 2003 00:35:41 -0700 Received: from 202.144.62.166 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 25 Jun 2003 07:35:41 GMT X-Originating-IP: [202.144.62.166] X-Originating-Email: [chaudharyanurag@hotmail.com] From: "Anurag Chaudhary" To: julian@elischer.org Date: Wed, 25 Jun 2003 13:05:41 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jun 2003 07:35:41.0565 (UTC) FILETIME=[614D3AD0:01C33AEC] cc: freebsd-threads@freebsd.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 07:35:42 -0000 its pthread library on freebsd 5.0 release >From: Julian Elischer >To: Anurag Chaudhary >CC: freebsd-threads@freebsd.org >Subject: Re: semaphores and multithreading >Date: Wed, 25 Jun 2003 00:33:02 -0700 (PDT) > >Which thread library are you using? >And on what release of the OS? > > >On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > > > hi > > > > I am having a multi-threaded application. the child thread has to wait >on a > > semaphore but when it does so the parent thread stops responding and >taking > > inputs from the keyboard. > > I tried changing the scheduling policy and priority of the child thread >but > > in vain. > > child thread is created with default attributes. > > Can anybody figure out some solution for this? > > > > urgent help required > > > > thanx > > Chaudhary Anurag > > > > _________________________________________________________________ > > Take this online tour. Win an HCL Beanstalk PC. > > http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html > > > > _______________________________________________ > > 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" > > > _________________________________________________________________ Smile a little. Enjoy the summer with Joggers' Park! http://server1.msn.co.in/sp03/joggerspark/index.asp From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 00:42:05 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3A7D37B401 for ; Wed, 25 Jun 2003 00:42:04 -0700 (PDT) Received: from sccrmhc12.attbi.com (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D5D343F75 for ; Wed, 25 Jun 2003 00:42:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc12) with ESMTP id <2003062507420301200fuhj6e>; Wed, 25 Jun 2003 07:42:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA98599; Wed, 25 Jun 2003 00:42:03 -0700 (PDT) Date: Wed, 25 Jun 2003 00:42:01 -0700 (PDT) From: Julian Elischer To: Anurag Chaudhary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 07:42:05 -0000 It is not going to be very helpful but you should upgrade to 5.1 (preferably -current) and try the two new pthread libraries.. (there are now 4) Threads support (real threads) is one of the main improvements to 5.1 On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > > its pthread library on freebsd 5.0 release > > >From: Julian Elischer > >To: Anurag Chaudhary > >CC: freebsd-threads@freebsd.org > >Subject: Re: semaphores and multithreading > >Date: Wed, 25 Jun 2003 00:33:02 -0700 (PDT) > > > >Which thread library are you using? > >And on what release of the OS? > > > > > >On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > > > > > hi > > > > > > I am having a multi-threaded application. the child thread has to wait > >on a > > > semaphore but when it does so the parent thread stops responding and > >taking > > > inputs from the keyboard. > > > I tried changing the scheduling policy and priority of the child thread > >but > > > in vain. > > > child thread is created with default attributes. > > > Can anybody figure out some solution for this? > > > > > > urgent help required > > > > > > thanx > > > Chaudhary Anurag > > > > > > _________________________________________________________________ > > > Take this online tour. Win an HCL Beanstalk PC. > > > http://server1.msn.co.in/sp03/hclbeanstalktour/amazing_winxp.html > > > > > > _______________________________________________ > > > 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" > > > > > > > _________________________________________________________________ > Smile a little. Enjoy the summer with Joggers' Park! > http://server1.msn.co.in/sp03/joggerspark/index.asp > > _______________________________________________ > 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 Wed Jun 25 03:23:19 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D51737B401 for ; Wed, 25 Jun 2003 03:23:19 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5658743FDF for ; Wed, 25 Jun 2003 03:23:15 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5PDQcnp011127 for ; Wed, 25 Jun 2003 13:26:39 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5PAUfrx012995; Wed, 25 Jun 2003 13:30:41 +0300 (EEST) (envelope-from phantom) Date: Wed, 25 Jun 2003 13:30:41 +0300 From: Alexey Zelkin To: threads@freebsd.org Message-ID: <20030625133041.A12986@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.7-STABLE i386 Subject: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 10:23:19 -0000 hi, Yesterday I have got to point then libkse & libthr testing reached top of my TODO list. Results are not that I expected and wanted to get. In my first expirement I have had 6 Jun's -CURRENT and very recent libkse and libthr. In this case at jdk14 build attempt I have expirienced strange behaviour of both libs: at compiling of big chunks of code java compiler stuck in "pause" mode forever. Well, I have made clean build & install with most recent world, kernel and libkse and found that "pause" lockups are not repearing anymore, but something still broken. While compiling of one of packages it's usual case then SIGSEGV is received by javac. In libc_r case it is usually catched by signalHandler(), handled and continued. But in libkse case signal is not even reached of signalHandler() routine. As soon as I do 'continue' in gdb I get another SIGSEGV with below backtrace. Looks like signals are still not really working in libkse. ps: I'll do same checking against libthr soon and notice you results. [..] Program received signal SIGSEGV, Segmentation fault. 0x28089e9b in __sys_sigprocmask () from /usr/lib/libkse.so.1 (gdb) bt full #0 0x28089e9b in __sys_sigprocmask () from /usr/lib/libkse.so.1 No symbol table info available. #1 0x28082c60 in kse_check_signals (curkse=0x8051000) at /home/phantom/src5/lib/libpthread/thread/thr_kern.c:1028 sigset = {__bits = {134549504, 134549664, 0, 134549508}} i = 134569876 #2 0x280828c0 in kse_sched_multi (curkse=0x8051000) at /home/phantom/src5/lib/libpthread/thread/thr_kern.c:884 curthread = (struct pthread *) 0x8058000 td_wait = (struct pthread *) 0x0 curframe = (struct pthread_sigframe *) 0x2edfe17b ret = 0 #3 0x08051000 in ?? () No symbol table info available. [..] From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 04:07:27 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B6D437B401 for ; Wed, 25 Jun 2003 04:07:27 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A19743FFD for ; Wed, 25 Jun 2003 04:07:21 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5PEAinp013891 for ; Wed, 25 Jun 2003 14:10:45 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5PBEkGH013226; Wed, 25 Jun 2003 14:14:47 +0300 (EEST) (envelope-from phantom) Date: Wed, 25 Jun 2003 14:14:46 +0300 From: Alexey Zelkin To: threads@freebsd.org Message-ID: <20030625141446.A13215@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.7-STABLE i386 Subject: libthr & jdk14: cv problems ? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 11:07:27 -0000 hi, Hmmm... libthr is also having problem with compiling jdk14. At some point (could not find a some logic in lockups yet), java processes lock up. I have expirienced few lockups and DDB's ps output looks almost same for all cases (examples below). For one of these lockups I have did gcore got backtrace (also below). IMPORTANT NOTE: I also should note that previous problem I posted about libkse about hour ago is NOT an issue for libthr. At least looks like, because with libthr build process passed far longer than with libkse. 44394 c4453d3c e0e76000 1001 44393 26249 0004002 [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac [CV]select 0xc038c5f4] javac [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac [SLP]pause 0xc472e000] javac 49226 c47d3974 e0ea1000 1001 49225 44442 0004002 [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java [CV]select 0xc038c5f4] java [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java [SLP]pause 0xc4a74000] java #0 0x280c9df3 in sigtimedwait () from /usr/lib/libc.so.5 No symbol table info available. #1 0x2807aadf in _thread_suspend (pthread=0x80513e4, abstime=0x0) at /home/phantom/src5/lib/libthr/thread/thr_kern.c:207 remaining = {tv_sec = -1080656532, tv_nsec = 671590325} ts = (struct timespec *) 0x159 info = {si_signo = -2147483644, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 671605680, si_status = 134544352, si_addr = 0xbf967d9c, si_value = { sigval_int = 671594420, sigval_ptr = 0x2807b7b4}, si_band = 134924288, __spare__ = {0, 0, 671600686, 134544380, 671605680, 3, 671605680}} set = {__bits = {134924328, 3214310740, 0, 0}} error = 345 #2 0x2807b7b4 in cond_wait_common (cond=0x80513e4, mutex=0x80513e0, abstime=0x0) at /home/phantom/src5/lib/libthr/thread/thr_cond.c:287 rval = 134544380 done = 134544352 seqno = 3 mtxrval = 345 #3 0x2807b4ae in _pthread_cond_wait (cond=0x159, mutex=0x159) at /home/phantom/src5/lib/libthr/thread/thr_cond.c:175 rval = 345 From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 05:08:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60CEF37B401 for ; Wed, 25 Jun 2003 05:08:13 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC6C543FF2 for ; Wed, 25 Jun 2003 05:08:06 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5PFBTnp017894 for ; Wed, 25 Jun 2003 15:11:31 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5PCFTxM013541; Wed, 25 Jun 2003 15:15:29 +0300 (EEST) (envelope-from phantom) Date: Wed, 25 Jun 2003 15:15:28 +0300 From: Alexey Zelkin To: threads@freebsd.org Message-ID: <20030625151528.A13514@phantom.cris.net> References: <20030625141446.A13215@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030625141446.A13215@phantom.cris.net>; from phantom@FreeBSD.org.ua on Wed, Jun 25, 2003 at 02:14:46PM +0300 X-Operating-System: FreeBSD 4.7-STABLE i386 Subject: more details (was: Re: libthr & jdk14: cv problems ?) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 12:08:13 -0000 hi, More details on libthr issue: First, there's no schema in lockups, i.e. while doing few clean rebuilds of jdk14 tree I have expirienced lockups in random places. Second, after I switched to debug version of java compiler (with lots of additional asserts and checks) I have hit into assert "suspend thread failed". Unfortunatelly I was unable to find exact place where this assert is trigerred because of 'third detail' (below). Quick source analyzis shown that most _probably_ this assert was trigerred because of pthread_resume_np() or pthread_cond_wait() functions returned non-successful value. Third, it is not possible to run application in gdb while libthr is default threading library. gdb always fails with: : Program received signal ?, Unknown signal. : 0x2811ca64 in _ctx_start () from /usr/lib/libc.so.5 : (gdb) bt : #0 0x2811ca64 in _ctx_start () from /usr/lib/libc.so.5 : #1 0x28077150 in _thread_start () : at /home/phantom/src5/lib/libthr/thread/thr_create.c:213 : (gdb) bt full : #0 0x2811ca64 in _ctx_start () from /usr/lib/libc.so.5 : No symbol table info available. : #1 0x28077150 in _thread_start () : at /home/phantom/src5/lib/libthr/thread/thr_create.c:213 : next_uniqueid = 3 : _thread_next_offset = 56 : _thread_uniqueid_offset = 8 : _thread_state_offset = 836 : _thread_name_offset = 4 : _thread_ctx_offset = 128 : _thread_PS_RUNNING_value = 0 : _thread_PS_DEAD_value = 6 : (gdb) From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 06:48:37 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A8E37B401 for ; Wed, 25 Jun 2003 06:48:37 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEE0243FEA for ; Wed, 25 Jun 2003 06:48:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5PDmUXh022903; Wed, 25 Jun 2003 09:48:30 -0400 (EDT) Date: Wed, 25 Jun 2003 09:48:30 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 13:48:37 -0000 On Wed, 25 Jun 2003, Julian Elischer wrote: > Which thread library are you using? > And on what release of the OS? > > > On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > > > hi > > > > I am having a multi-threaded application. the child thread has to wait on a > > semaphore but when it does so the parent thread stops responding and taking > > inputs from the keyboard. > > I tried changing the scheduling policy and priority of the child thread but > > in vain. > > child thread is created with default attributes. > > Can anybody figure out some solution for this? What kind of semaphores? Libc_r and SysV semaphores will not work together. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 06:55:24 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3A9F37B401 for ; Wed, 25 Jun 2003 06:55:24 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A8C143F93 for ; Wed, 25 Jun 2003 06:55:24 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5PDtMXh023938; Wed, 25 Jun 2003 09:55:22 -0400 (EDT) Date: Wed, 25 Jun 2003 09:55:21 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alexey Zelkin In-Reply-To: <20030625133041.A12986@phantom.cris.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 13:55:25 -0000 On Wed, 25 Jun 2003, Alexey Zelkin wrote: > hi, > > Yesterday I have got to point then libkse & libthr testing > reached top of my TODO list. Results are not that I expected and > wanted to get. > > In my first expirement I have had 6 Jun's -CURRENT and very recent > libkse and libthr. In this case at jdk14 build attempt I have > expirienced strange behaviour of both libs: at compiling of big > chunks of code java compiler stuck in "pause" mode forever. > > Well, I have made clean build & install with most recent world, > kernel and libkse and found that "pause" lockups are not repearing > anymore, but something still broken. While compiling of one of > packages it's usual case then SIGSEGV is received by javac. In > libc_r case it is usually catched by signalHandler(), handled > and continued. But in libkse case signal is not even reached > of signalHandler() routine. As soon as I do 'continue' in gdb > I get another SIGSEGV with below backtrace. > > Looks like signals are still not really working in libkse. David Xu is revamping signal handling (it also involves some kernel changes). Very alpha patches are at: http://people.freebsd.org/~davidxu/kse_sig/ They are not yet completely working, but might help. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 09:16:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E07FE37B405 for ; Wed, 25 Jun 2003 09:16:04 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F5143FE3 for ; Wed, 25 Jun 2003 09:16:02 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5PJJSnp034052; Wed, 25 Jun 2003 19:19:28 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5PGNQ0Z015458; Wed, 25 Jun 2003 19:23:26 +0300 (EEST) (envelope-from phantom) Date: Wed, 25 Jun 2003 19:23:26 +0300 From: Alexey Zelkin To: Daniel Eischen Message-ID: <20030625192326.A15424@phantom.cris.net> References: <20030625133041.A12986@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Wed, Jun 25, 2003 at 09:55:21AM -0400 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: threads@freebsd.org Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 16:16:05 -0000 hi, On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > hi, > > > > Yesterday I have got to point then libkse & libthr testing > > reached top of my TODO list. Results are not that I expected and > > wanted to get. > > > > In my first expirement I have had 6 Jun's -CURRENT and very recent > > libkse and libthr. In this case at jdk14 build attempt I have > > expirienced strange behaviour of both libs: at compiling of big > > chunks of code java compiler stuck in "pause" mode forever. > > > > Well, I have made clean build & install with most recent world, > > kernel and libkse and found that "pause" lockups are not repearing > > anymore, but something still broken. While compiling of one of > > packages it's usual case then SIGSEGV is received by javac. In > > libc_r case it is usually catched by signalHandler(), handled > > and continued. But in libkse case signal is not even reached > > of signalHandler() routine. As soon as I do 'continue' in gdb > > I get another SIGSEGV with below backtrace. > > > > Looks like signals are still not really working in libkse. > > David Xu is revamping signal handling (it also involves > some kernel changes). Very alpha patches are at: > > http://people.freebsd.org/~davidxu/kse_sig/ > > They are not yet completely working, but might help. Cool! It really helped. At least visible behaviour is same to libc_r. /me running TCK tests... From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 16:07:37 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4496237B401 for ; Wed, 25 Jun 2003 16:07:37 -0700 (PDT) Received: from hotmail.com (law9-f99.law9.hotmail.com [64.4.9.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA13E44013 for ; Wed, 25 Jun 2003 16:07:36 -0700 (PDT) (envelope-from chaudharyanurag@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jun 2003 16:07:34 -0700 Received: from 219.65.234.4 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 25 Jun 2003 23:07:34 GMT X-Originating-IP: [219.65.234.4] X-Originating-Email: [chaudharyanurag@hotmail.com] From: "Anurag Chaudhary" To: eischen@vigrid.com, julian@elischer.org Date: Thu, 26 Jun 2003 04:37:34 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jun 2003 23:07:34.0817 (UTC) FILETIME=[90326910:01C33B6E] cc: freebsd-threads@freebsd.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 23:07:37 -0000 I am using sys V semaphores with pthread library on freebsd 5.0 release >From: Daniel Eischen >To: Julian Elischer >CC: Anurag Chaudhary , >freebsd-threads@freebsd.org >Subject: Re: semaphores and multithreading >Date: Wed, 25 Jun 2003 09:48:30 -0400 (EDT) > >On Wed, 25 Jun 2003, Julian Elischer wrote: > > > Which thread library are you using? > > And on what release of the OS? > > > > > > On Wed, 25 Jun 2003, Anurag Chaudhary wrote: > > > > > hi > > > > > > I am having a multi-threaded application. the child thread has to wait >on a > > > semaphore but when it does so the parent thread stops responding and >taking > > > inputs from the keyboard. > > > I tried changing the scheduling policy and priority of the child >thread but > > > in vain. > > > child thread is created with default attributes. > > > Can anybody figure out some solution for this? > >What kind of semaphores? Libc_r and SysV semaphores will not work >together. > >-- >Dan Eischen > _________________________________________________________________ Smile a little. Enjoy the summer with Joggers' Park! http://server1.msn.co.in/sp03/joggerspark/index.asp From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 18:08:53 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E42137B405; Wed, 25 Jun 2003 18:08:53 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC04143FAF; Wed, 25 Jun 2003 18:08:51 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h5Q18mUp097573; Wed, 25 Jun 2003 18:08:49 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <004d01c33b7f$ede4dc30$f001a8c0@davidw2k> From: "David Xu" To: "Alexey Zelkin" , "Daniel Eischen" References: <20030625133041.A12986@phantom.cris.net> <20030625192326.A15424@phantom.cris.net> Date: Thu, 26 Jun 2003 09:11:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 01:08:53 -0000 ----- Original Message -----=20 From: "Alexey Zelkin" To: "Daniel Eischen" Cc: Sent: Thursday, June 26, 2003 12:23 AM Subject: Re: libkse & jdk14: signals(?) breakage > hi, >=20 > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > >=20 > > > hi, > > > ... > > > Looks like signals are still not really working in libkse. > >=20 > > David Xu is revamping signal handling (it also involves > > some kernel changes). Very alpha patches are at: > >=20 > > http://people.freebsd.org/~davidxu/kse_sig/ > >=20 > > They are not yet completely working, but might help. >=20 > Cool! It really helped. At least visible behaviour is same to = libc_r. >=20 Your test is appreciated. I have updated the patches again, they have past signal test suites included in libpthread. Can you test these new patches again ? http://people.freebsd.org/~davidxu/kse_sig/kern.diff http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz I am now working on code cleanup... > /me running TCK tests... > _______________________________________________ > 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" >=20 From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 20:01:43 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED87637B401; Wed, 25 Jun 2003 20:01:42 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CF8C4400B; Wed, 25 Jun 2003 20:01:42 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5Q31eXh027645; Wed, 25 Jun 2003 23:01:40 -0400 (EDT) Date: Wed, 25 Jun 2003 23:01:40 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <004d01c33b7f$ede4dc30$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Alexey Zelkin Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 03:01:43 -0000 On Thu, 26 Jun 2003, David Xu wrote: > From: "Alexey Zelkin" > > > hi, > > > > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > > > > > hi, > > > > ... > > > > Looks like signals are still not really working in libkse. > > > > > > David Xu is revamping signal handling (it also involves > > > some kernel changes). Very alpha patches are at: > > > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > > > > They are not yet completely working, but might help. > > > > Cool! It really helped. At least visible behaviour is same to libc_r. > > > > Your test is appreciated. I have updated the patches again, > they have past signal test suites included in libpthread. > Can you test these new patches again ? > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz > > I am now working on code cleanup... Does this fix the problems that I was seeing? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 20:28:05 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C365937B401; Wed, 25 Jun 2003 20:28:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6242743FD7; Wed, 25 Jun 2003 20:28:05 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h5Q3S2Up009864; Wed, 25 Jun 2003 20:28:03 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <013101c33b93$6128f010$f001a8c0@davidw2k> From: "David Xu" To: References: Date: Thu, 26 Jun 2003 11:31:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org cc: Alexey Zelkin Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 03:28:06 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: ; "Alexey Zelkin" Sent: Thursday, June 26, 2003 11:01 AM Subject: Re: libkse & jdk14: signals(?) breakage > On Thu, 26 Jun 2003, David Xu wrote: >=20 > > From: "Alexey Zelkin" > >=20 > > > hi, > > >=20 > > > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > >=20 > > > > > hi, > > > > > ... > > > > > Looks like signals are still not really working in libkse. > > > >=20 > > > > David Xu is revamping signal handling (it also involves > > > > some kernel changes). Very alpha patches are at: > > > >=20 > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > >=20 > > > > They are not yet completely working, but might help. > > >=20 > > > Cool! It really helped. At least visible behaviour is same to = libc_r. > > >=20 > >=20 > > Your test is appreciated. I have updated the patches again, > > they have past signal test suites included in libpthread. > > Can you test these new patches again ? > > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz > >=20 > > I am now working on code cleanup... >=20 > Does this fix the problems that I was seeing? >=20 Yes. :-) > --=20 > Dan Eischen >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 21:47:03 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10BB437B401 for ; Wed, 25 Jun 2003 21:47:03 -0700 (PDT) Received: from hotmail.com (law9-f4.law9.hotmail.com [64.4.9.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A83FB44030 for ; Wed, 25 Jun 2003 21:47:02 -0700 (PDT) (envelope-from chaudharyanurag@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jun 2003 21:47:02 -0700 Received: from 202.144.62.166 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 26 Jun 2003 04:47:02 GMT X-Originating-IP: [202.144.62.166] X-Originating-Email: [chaudharyanurag@hotmail.com] From: "Anurag Chaudhary" To: freebsd-threads@freebsd.org Date: Thu, 26 Jun 2003 10:17:02 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jun 2003 04:47:02.0552 (UTC) FILETIME=[FC502180:01C33B9D] Subject: threads and semaphores X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 04:47:03 -0000 hi how can I keep my parent thread working and responding to user inputs while the child thread is waiting for a semaphore using semop() which is held by some other process. In linux the parent thread remains active in such situation but in freebsd the parent thread stops responding until the child thread returns from semop(). Is this implementation dependent feature. Is there something that lets the child thread release resources while waiting for the semaphore. I used pthread_yield() but didn't work. I also tried to change the scheduling policy and priority of the child thread but of no use. I am using sys V threads with pthread library on freebsd 5.0 release. Actually I am porting this code from linux to freebsd and facing this problem somebody please suggest some workaround thanx Chaudhary Anurag _________________________________________________________________ Gift yourself a holiday. Treat your family like royalty. http://www.flexihols.com/2003/index.php From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 22:03:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B13A37B401 for ; Wed, 25 Jun 2003 22:03:25 -0700 (PDT) Received: from lakemtao07.cox.net (lakemtao07.cox.net [68.1.17.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id B60E643FF5 for ; Wed, 25 Jun 2003 22:03:24 -0700 (PDT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.11]) by lakemtao07.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030626050323.GSCP4514.lakemtao07.cox.net@mezz.mezzweb.com>; Thu, 26 Jun 2003 01:03:23 -0400 To: Anurag Chaudhary References: Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed From: Jeremy Messenger MIME-Version: 1.0 Date: Thu, 26 Jun 2003 00:03:29 -0500 In-Reply-To: User-Agent: Opera7.11/Linux M2 build 406 cc: freebsd-threads@freebsd.org Subject: Re: threads and semaphores X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 05:03:25 -0000 On Thu, 26 Jun 2003 10:17:02 +0530, Anurag Chaudhary wrote: > hi > > how can I keep my parent thread working and responding to user inputs > while the child thread is waiting for a semaphore using semop() which is > held by some other process. > In linux the parent thread remains active in such situation but in > freebsd the parent thread stops responding until the child thread returns > from semop(). > Is this implementation dependent feature. > Is there something that lets the child thread release resources while > waiting for the semaphore. > I used pthread_yield() but didn't work. > I also tried to change the scheduling policy and priority of the child > thread but of no use. > I am using sys V threads with pthread library on freebsd 5.0 release. You do really need to update your FreeBSD to 5.1 if you want to play with the libkse/libthr (thread).. Cheers, Mezz > Actually I am porting this code from linux to freebsd and facing this > problem > > somebody please suggest some workaround > > thanx > Chaudhary Anurag -- bsdforums.org 's moderator, mezz. From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 22:12:51 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF9C737B401 for ; Wed, 25 Jun 2003 22:12:51 -0700 (PDT) Received: from hotmail.com (law9-f84.law9.hotmail.com [64.4.9.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D68644017 for ; Wed, 25 Jun 2003 22:12:51 -0700 (PDT) (envelope-from chaudharyanurag@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jun 2003 22:12:51 -0700 Received: from 202.144.62.166 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 26 Jun 2003 05:12:50 GMT X-Originating-IP: [202.144.62.166] X-Originating-Email: [chaudharyanurag@hotmail.com] From: "Anurag Chaudhary" To: mezz7@cox.net Date: Thu, 26 Jun 2003 10:42:50 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jun 2003 05:12:51.0106 (UTC) FILETIME=[9752B820:01C33BA1] cc: freebsd-threads@freebsd.org Subject: Re: threads and semaphores X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 05:12:52 -0000 Is multithreading more robust and secure in freebsd 5.1 than freebsd 5.0? >From: Jeremy Messenger >To: Anurag Chaudhary >CC: freebsd-threads@freebsd.org >Subject: Re: threads and semaphores >Date: Thu, 26 Jun 2003 00:03:29 -0500 > >On Thu, 26 Jun 2003 10:17:02 +0530, Anurag Chaudhary > wrote: > >>hi >> >>how can I keep my parent thread working and responding to user inputs >>while the child thread is waiting for a semaphore using semop() which is >>held by some other process. >>In linux the parent thread remains active in such situation but in freebsd >>the parent thread stops responding until the child thread returns from >>semop(). >>Is this implementation dependent feature. >>Is there something that lets the child thread release resources while >>waiting for the semaphore. >>I used pthread_yield() but didn't work. >>I also tried to change the scheduling policy and priority of the child >>thread but of no use. >>I am using sys V threads with pthread library on freebsd 5.0 release. > >You do really need to update your FreeBSD to 5.1 if you want to play with >the libkse/libthr (thread).. > >Cheers, >Mezz > >>Actually I am porting this code from linux to freebsd and facing this >>problem >> >>somebody please suggest some workaround >> >>thanx >>Chaudhary Anurag > > >-- >bsdforums.org 's moderator, mezz. _________________________________________________________________ Are you a geek? Are you a techno freak? http://www.msn.co.in/Computing/ From owner-freebsd-threads@FreeBSD.ORG Wed Jun 25 22:12:56 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C779637B401 for ; Wed, 25 Jun 2003 22:12:56 -0700 (PDT) Received: from sccrmhc11.attbi.com (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13C174402D for ; Wed, 25 Jun 2003 22:12:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc11) with ESMTP id <2003062605125401100s5an3e>; Thu, 26 Jun 2003 05:12:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA07324; Wed, 25 Jun 2003 22:12:52 -0700 (PDT) Date: Wed, 25 Jun 2003 22:12:51 -0700 (PDT) From: Julian Elischer To: Anurag Chaudhary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: threads and semaphores X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 05:12:57 -0000 upgrade to 5.1 and use libthr or libkse (actually, 5.1++ (-current) would be best. OR link with the linuxthreads port. On Thu, 26 Jun 2003, Anurag Chaudhary wrote: > hi > > how can I keep my parent thread working and responding to user inputs while > the child thread is waiting for a semaphore using semop() which is held by > some other process. > In linux the parent thread remains active in such situation but in freebsd > the parent thread stops responding until the child thread returns from > semop(). > Is this implementation dependent feature. > Is there something that lets the child thread release resources while > waiting for the semaphore. > I used pthread_yield() but didn't work. > I also tried to change the scheduling policy and priority of the child > thread but of no use. > I am using sys V threads with pthread library on freebsd 5.0 release. > Actually I am porting this code from linux to freebsd and facing this > problem > > somebody please suggest some workaround > > thanx > Chaudhary Anurag > > _________________________________________________________________ > Gift yourself a holiday. Treat your family like royalty. > http://www.flexihols.com/2003/index.php > > _______________________________________________ > 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 Wed Jun 25 22:16:39 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFD8C37B401 for ; Wed, 25 Jun 2003 22:16:39 -0700 (PDT) Received: from sccrmhc12.attbi.com (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3495343FF3 for ; Wed, 25 Jun 2003 22:16:35 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc12) with ESMTP id <2003062605163301200d9fl0e>; Thu, 26 Jun 2003 05:16:34 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA07362; Wed, 25 Jun 2003 22:16:33 -0700 (PDT) Date: Wed, 25 Jun 2003 22:16:32 -0700 (PDT) From: Julian Elischer To: Anurag Chaudhary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: threads and semaphores X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 05:16:40 -0000 much. It's one of the main differences between 5.0 and 5.1 in fact you shoudl go past 5.1 and use 5.1++ -current as of next week if you can wait a while... (you should link with either libkse or libthr, OR you can link as before but remap which threds library to use at runtime using teh libmap stuff. in the meanwhile, since your app links on linux you should be able to use the linux threads port for FreeBSD On Thu, 26 Jun 2003, Anurag Chaudhary wrote: > Is multithreading more robust and secure in freebsd 5.1 than freebsd 5.0? > > >From: Jeremy Messenger > >To: Anurag Chaudhary > >CC: freebsd-threads@freebsd.org > >Subject: Re: threads and semaphores > >Date: Thu, 26 Jun 2003 00:03:29 -0500 > > > >On Thu, 26 Jun 2003 10:17:02 +0530, Anurag Chaudhary > > wrote: > > > >>hi > >> > >>how can I keep my parent thread working and responding to user inputs > >>while the child thread is waiting for a semaphore using semop() which is > >>held by some other process. > >>In linux the parent thread remains active in such situation but in freebsd > >>the parent thread stops responding until the child thread returns from > >>semop(). > >>Is this implementation dependent feature. > >>Is there something that lets the child thread release resources while > >>waiting for the semaphore. > >>I used pthread_yield() but didn't work. > >>I also tried to change the scheduling policy and priority of the child > >>thread but of no use. > >>I am using sys V threads with pthread library on freebsd 5.0 release. > > > >You do really need to update your FreeBSD to 5.1 if you want to play with > >the libkse/libthr (thread).. > > > >Cheers, > >Mezz > > > >>Actually I am porting this code from linux to freebsd and facing this > >>problem > >> > >>somebody please suggest some workaround > >> > >>thanx > >>Chaudhary Anurag > > > > > >-- > >bsdforums.org 's moderator, mezz. > > _________________________________________________________________ > Are you a geek? Are you a techno freak? http://www.msn.co.in/Computing/ > > _______________________________________________ > 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 Wed Jun 25 23:14:11 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCDC137B401 for ; Wed, 25 Jun 2003 23:14:11 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4662B44031 for ; Wed, 25 Jun 2003 23:14:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfirs.dialup.mindspring.com ([165.247.203.124] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19VQ1I-00001W-00; Wed, 25 Jun 2003 23:14:08 -0700 Message-ID: <3EFA8EEB.1E0842D5@mindspring.com> Date: Wed, 25 Jun 2003 23:12:59 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anurag Chaudhary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a415d3f081818e80c60f446f9d24cb6968350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org cc: julian@elischer.org Subject: Re: semaphores and multithreading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 06:14:12 -0000 Anurag Chaudhary wrote: > I am using sys V semaphores with pthread library on freebsd 5.0 release There are 4 pthread libraries on FreeBSD 5.x-current. Most likely, you are compiling with "-pthread" or something like that. What people are asking you is if you are explicitly linking against a specific threads library, rather than using a compiler/linker option that gives you the library that the system wants you to have. Currently, a manual linkage would require you to specify one of (ignoring the fourth, which is Linux threads from ports): -lc_r <-- historical N:1 threads library -lthr <-- 1:1 threads library -lkse <-- N:M threads library to get threads. The default in 5.0-RELEASE was "-lc_r". If you are using an N:1 threads library, you have only a single kernel blocking context; it operates using a user space call conversion scheduler. This operates for converting a blocking system call into a non-blocking equivalent, and triggering a context switch. System V semaphores do not have non-blocking equivalents for use in implementing a call conversion; therefore, if you call one of these functions, you will end up blocking in the kernel on a blocking primitive, and hanging until the resource becomes available: all threads in the process with the blocking thread will also be blocked. You should convert to using libthr, libkse, or the Linux threads library (which has license issues, relative to the FreeBSD way of looking at things). To use libthr or libkse, you will need to switch your system over from 5.0 to -current. -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 10:32:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27A1537B401 for ; Thu, 26 Jun 2003 10:32:31 -0700 (PDT) Received: from titan.exolab.org (smtp.intalio.com [65.222.219.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B63643F85 for ; Thu, 26 Jun 2003 10:32:30 -0700 (PDT) (envelope-from boisvert@intalio.com) Received: from intalio.com (fwin.intalio.com [65.222.219.17]) by titan.exolab.org (8.11.1/8.11.1) with ESMTP id h5QHWTE20661 for ; Thu, 26 Jun 2003 10:32:29 -0700 Message-ID: <3EFB2E12.3080504@intalio.com> Date: Thu, 26 Jun 2003 10:32:02 -0700 From: Alex Boisvert User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 17:32:31 -0000 Hi, I written a small test case (see source below), which I've run against both libkse and libthr. I'm using -CURRENT as of last Tuesday and running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). With libkse, the program runs most of the time (say, about 9 times out of 10) but sometimes hang and, interestingly, prints an "F" character to the console -- but that "F" character is never printed by the application itself! (see source) Here are two examples of when it hangs: bipolar:boisvert:~/prog/pthread:48 gcc -g -lkse -o foo2 foo2.c bipolar:boisvert:~/prog/pthread:49 ./foo2 1000 Using 1000 threads (parameter) bar 0 bar 1 bar 2 Fbar 3 ^C bipolar:boisvert:~/prog/pthread:50 (Notice the "F" on the last line, before I had to use CTRL-C to terminate the application). Also, sometimes I get: bipolar:boisvert:~/prog/pthread:65 ./foo2 1000 Using 1000 threads (parameter) F ^C bipolar:boisvert:~/prog/pthread:66 I also tried the same test case with libthr and got a different behavior: bipolar:boisvert:~/prog/pthread:141 gcc -g -lthr -o foo2 foo2.c bipolar:boisvert:~/prog/pthread:142 ./foo2 1000 Using 1000 threads (parameter) bar 0 foo2: Unknown error: 0 bipolar:boisvert:~/prog/pthread:143 In this case, the behavior is more easily reproductible. So, maybe you can help me figure out if my test case is somehow invalid or these are genuine problems within the threading libraries... cheers, alex ----------- foo2.c #include #include #include void *foo(void *); typedef struct { int number; } arg_t; /** * Simple test case for the thread system. Start "n" threads, * and join them afterwards. */ int main( int argc, char** argv) { pthread_t* threads; arg_t* args; void* ret; int n; int i; if ( argc > 1 ) { n = strtoimax( argv[1], NULL, 10 ); printf( "Using %d threads (parameter)\n", n ); } else { n = 5; printf( "Using %d threads (default)\n", n ); } // initialize random number generator srandomdev(); threads = (pthread_t*) malloc( sizeof(pthread_t) * n ); args = (arg_t*) malloc( sizeof(arg_t) * n ); // start n threads for ( i=0; i Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E661137B401 for ; Thu, 26 Jun 2003 11:27:56 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F9043FBF for ; Thu, 26 Jun 2003 11:27:55 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5QIRsXh018245; Thu, 26 Jun 2003 14:27:54 -0400 (EDT) Date: Thu, 26 Jun 2003 14:27:54 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alex Boisvert In-Reply-To: <3EFB2E12.3080504@intalio.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@gdeb.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 18:27:57 -0000 On Thu, 26 Jun 2003, Alex Boisvert wrote: > Hi, > > I written a small test case (see source below), which I've run against > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). > > With libkse, the program runs most of the time (say, about 9 times out > of 10) but sometimes hang and, interestingly, prints an "F" character to > the console -- but that "F" character is never printed by the > application itself! (see source) > > Here are two examples of when it hangs: > > bipolar:boisvert:~/prog/pthread:48 gcc -g -lkse -o foo2 foo2.c > bipolar:boisvert:~/prog/pthread:49 ./foo2 1000 > Using 1000 threads (parameter) > bar 0 > bar 1 > bar 2 > Fbar 3 > ^C > bipolar:boisvert:~/prog/pthread:50 > > (Notice the "F" on the last line, before I had to use CTRL-C to > terminate the application). > > Also, sometimes I get: > > bipolar:boisvert:~/prog/pthread:65 ./foo2 1000 > Using 1000 threads (parameter) > F > ^C > bipolar:boisvert:~/prog/pthread:66 I don't really see anything wrong with your test program. There would seem to be a bug in libkse or perhaps even in libc (stdio not being thread-safe or something). We've got some changes in the works. I'll check them out with your test program. Thanks! -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 13:36:29 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86C9B37B401 for ; Thu, 26 Jun 2003 13:36:29 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4D543F3F for ; Thu, 26 Jun 2003 13:36:28 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5QKaSDZ019414; Thu, 26 Jun 2003 13:36:28 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5QKaShn037359; Thu, 26 Jun 2003 13:36:28 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5QKaOde037358; Thu, 26 Jun 2003 13:36:24 -0700 (PDT) (envelope-from marcel) Date: Thu, 26 Jun 2003 13:36:24 -0700 From: Marcel Moolenaar To: Alex Boisvert Message-ID: <20030626203624.GA37317@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EFB2E12.3080504@intalio.com> User-Agent: Mutt/1.5.4i cc: freebsd-threads@freebsd.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 20:36:29 -0000 On Thu, Jun 26, 2003 at 10:32:02AM -0700, Alex Boisvert wrote: > > I written a small test case (see source below), which I've run against > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). On ia64 I get the following with libthr (libkse is not completely ported yet): % ./foo2 1000 [very long list of random "bar #" : bar 999 bar 226 bar 244 Thread (_thread_initial:0) already on mutexq Fatal error 'Illegal call from signal handler' at line 1347 in file /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) The same happens with 100 threads. And the failure is one out of 5 runs or something less predictable. The 'F' you see comes from "Fatal error" AFAICT. Note that I don't have any of David's signal code patches applied. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 14:02:21 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3197B37B404 for ; Thu, 26 Jun 2003 14:02:21 -0700 (PDT) Received: from rwcrmhc12.attbi.com (rwcrmhc12.attbi.com [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C72243FF2 for ; Thu, 26 Jun 2003 14:02:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <200306262102090140073a31e>; Thu, 26 Jun 2003 21:02:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA13339; Thu, 26 Jun 2003 14:02:07 -0700 (PDT) Date: Thu, 26 Jun 2003 14:02:06 -0700 (PDT) From: Julian Elischer To: deischen@gdeb.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 21:02:21 -0000 On Thu, 26 Jun 2003, Daniel Eischen wrote: > On Thu, 26 Jun 2003, Alex Boisvert wrote: > > Hi, > > > > I written a small test case (see source below), which I've run against > > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). > > > > With libkse, the program runs most of the time (say, about 9 times out > > of 10) but sometimes hang and, interestingly, prints an "F" character to > > the console -- but that "F" character is never printed by the > > application itself! (see source) > > > > Here are two examples of when it hangs: > > > > bipolar:boisvert:~/prog/pthread:48 gcc -g -lkse -o foo2 foo2.c > > bipolar:boisvert:~/prog/pthread:49 ./foo2 1000 > > Using 1000 threads (parameter) > > bar 0 > > bar 1 > > bar 2 > > Fbar 3 > > ^C > > bipolar:boisvert:~/prog/pthread:50 > > > > (Notice the "F" on the last line, before I had to use CTRL-C to > > terminate the application). > > > > Also, sometimes I get: > > > > bipolar:boisvert:~/prog/pthread:65 ./foo2 1000 > > Using 1000 threads (parameter) > > F > > ^C > > bipolar:boisvert:~/prog/pthread:66 > > I don't really see anything wrong with your test program. There > would seem to be a bug in libkse or perhaps even in libc (stdio > not being thread-safe or something). > > We've got some changes in the works. I'll check them out > with your test program. Thanks! There is sonething slightly wrong in the KSE system as eventeh kse test program doesn't start up correctly occasionally. From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 14:45:05 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F3937B401; Thu, 26 Jun 2003 14:45:05 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C2E43FEC; Thu, 26 Jun 2003 14:45:01 -0700 (PDT) (envelope-from ml@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5R0mhnp044649; Fri, 27 Jun 2003 00:48:43 GMT Received: (from ml@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5QLqP2F025742; Fri, 27 Jun 2003 00:52:25 +0300 (EEST) (envelope-from ml) Date: Fri, 27 Jun 2003 00:52:25 +0300 From: Alexey Zelkin To: David Xu Message-ID: <20030627005225.A25700@phantom.cris.net> References: <20030625133041.A12986@phantom.cris.net> <20030625192326.A15424@phantom.cris.net> <004d01c33b7f$ede4dc30$f001a8c0@davidw2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004d01c33b7f$ede4dc30$f001a8c0@davidw2k>; from davidxu@freebsd.org on Thu, Jun 26, 2003 at 09:11:32AM +0800 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: threads@freebsd.org Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 21:45:05 -0000 hi, On Thu, Jun 26, 2003 at 09:11:32AM +0800, David Xu wrote: > > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > > > > > hi, > > > > ... > > > > Looks like signals are still not really working in libkse. > > > > > > David Xu is revamping signal handling (it also involves > > > some kernel changes). Very alpha patches are at: > > > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > > > > They are not yet completely working, but might help. > > > > Cool! It really helped. At least visible behaviour is same to libc_r. > > > > Your test is appreciated. I have updated the patches again, > they have past signal test suites included in libpthread. > Can you test these new patches again ? > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz It just works. Comparing to first signal patches it behaves even better. I did not see any random process lockups. Build & all TCK's VM tests passed. Good job! > I am now working on code cleanup... > > > /me running TCK tests... From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 17:21:57 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3A7E37B401 for ; Thu, 26 Jun 2003 17:21:56 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26F4543FD7 for ; Thu, 26 Jun 2003 17:21:56 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.140.205]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net>; Thu, 26 Jun 2003 19:21:55 -0500 Date: Thu, 26 Jun 2003 20:21:54 -0400 From: Mike Makonnen To: Marcel Moolenaar In-Reply-To: <20030626203624.GA37317@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [138.88.140.205] at Thu, 26 Jun 2003 19:21:54 -0500 Message-Id: <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 00:21:57 -0000 On Thu, 26 Jun 2003 13:36:24 -0700 Marcel Moolenaar wrote: > On Thu, Jun 26, 2003 at 10:32:02AM -0700, Alex Boisvert wrote: > > > > I written a small test case (see source below), which I've run against > > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). On i386 libthr limits an application to 128 _concurrent_ threads. So, you should check the return value from pthread_create() for EAGAIN, in which case you should retry again. > On ia64 I get the following with libthr (libkse is not completely > ported yet): > > % ./foo2 1000 > [very long list of random "bar #" > : > bar 999 > bar 226 > bar 244 > Thread (_thread_initial:0) already on mutexq > Fatal error 'Illegal call from signal handler' at line 1347 in file > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) Great! I've been waiting for this message to appear for some time. Do you have a backtrace by any chance? If not, that's Ok, even without it the program is simple enough that I know where to start looking. > Note that I don't have any of David's signal code patches applied. Any unbreaking of signals in the kernel would definitely help libthr. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 17:39:24 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5E8137B401 for ; Thu, 26 Jun 2003 17:39:24 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6291C43FDF for ; Thu, 26 Jun 2003 17:39:23 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R0dNDZ020391; Thu, 26 Jun 2003 17:39:23 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R0dMhn038150; Thu, 26 Jun 2003 17:39:22 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5R0dMgZ038149; Thu, 26 Jun 2003 17:39:22 -0700 (PDT) (envelope-from marcel) Date: Thu, 26 Jun 2003 17:39:22 -0700 From: Marcel Moolenaar To: Mike Makonnen Message-ID: <20030627003922.GA38103@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> User-Agent: Mutt/1.5.4i cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 00:39:24 -0000 On Thu, Jun 26, 2003 at 08:21:54PM -0400, Mike Makonnen wrote: > > > > % ./foo2 1000 > > [very long list of random "bar #" > > : > > bar 999 > > bar 226 > > bar 244 > > Thread (_thread_initial:0) already on mutexq > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > Great! I've been waiting for this message to appear for some time. Do you have a > backtrace by any chance? gdb(1) hasn't been ported yet, so no. BTW: The thread is not always _thread_initial... > > Note that I don't have any of David's signal code patches applied. > > Any unbreaking of signals in the kernel would definitely help libthr. If it's expected to make a difference, I can grab them and try again. Just say the word... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 17:41:39 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4B37B401 for ; Thu, 26 Jun 2003 17:41:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD8C43FE9 for ; Thu, 26 Jun 2003 17:41:39 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5R0fXXh022184; Thu, 26 Jun 2003 20:41:34 -0400 (EDT) Date: Thu, 26 Jun 2003 20:41:33 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 00:41:39 -0000 On Thu, 26 Jun 2003, Julian Elischer wrote: > On Thu, 26 Jun 2003, Daniel Eischen wrote: > > > On Thu, 26 Jun 2003, Alex Boisvert wrote: > > > Hi, > > > > > > I written a small test case (see source below), which I've run against > > > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > > > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). > > > > > > With libkse, the program runs most of the time (say, about 9 times out > > > of 10) but sometimes hang and, interestingly, prints an "F" character to > > > the console -- but that "F" character is never printed by the > > > application itself! (see source) > > > > > > Here are two examples of when it hangs: > > > [ ... ] > There is sonething slightly wrong in the KSE system as eventeh kse test > program doesn't start up correctly occasionally. I can't get either to fail... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 17:48:23 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ACA837B401; Thu, 26 Jun 2003 17:48:23 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F23043FE1; Thu, 26 Jun 2003 17:48:22 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5R0mLXh023163; Thu, 26 Jun 2003 20:48:21 -0400 (EDT) Date: Thu, 26 Jun 2003 20:48:21 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alexey Zelkin In-Reply-To: <20030627005225.A25700@phantom.cris.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 00:48:23 -0000 On Fri, 27 Jun 2003, Alexey Zelkin wrote: > hi, > > On Thu, Jun 26, 2003 at 09:11:32AM +0800, David Xu wrote: > > > > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > > > > > > > hi, > > > > > ... > > > > > Looks like signals are still not really working in libkse. > > > > > > > > David Xu is revamping signal handling (it also involves > > > > some kernel changes). Very alpha patches are at: > > > > > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > > > > > > They are not yet completely working, but might help. > > > > > > Cool! It really helped. At least visible behaviour is same to libc_r. > > > > > > > Your test is appreciated. I have updated the patches again, > > they have past signal test suites included in libpthread. > > Can you test these new patches again ? > > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz > > It just works. Comparing to first signal patches it behaves even > better. I did not see any random process lockups. Build & all TCK's > VM tests passed. Wow, that's great news. Do you have an SMP system to try the TCK tests on? Libpthread will automatically create as many KSEs as you have CPUs. Do you have any performance benchmarks so we can compare against libc_r (or even libthr)? BTW, thanks for taking the time to run these tests :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 17:55:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3440837B401 for ; Thu, 26 Jun 2003 17:55:25 -0700 (PDT) Received: from InterJet.elischer.org (12-233-125-100.client.attbi.com [12.233.125.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B2443FEA for ; Thu, 26 Jun 2003 17:55:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA15908; Thu, 26 Jun 2003 17:55:20 -0700 (PDT) Date: Thu, 26 Jun 2003 17:55:18 -0700 (PDT) From: Julian Elischer To: Mike Makonnen In-Reply-To: <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@FreeBSD.org cc: Marcel Moolenaar Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 00:55:25 -0000 On Thu, 26 Jun 2003, Mike Makonnen wrote: > On Thu, 26 Jun 2003 13:36:24 -0700 > Marcel Moolenaar wrote: > > > On Thu, Jun 26, 2003 at 10:32:02AM -0700, Alex Boisvert wrote: > > > > > > I written a small test case (see source below), which I've run against > > > both libkse and libthr. I'm using -CURRENT as of last Tuesday and > > > running on a Dual Athlon MP 1.2 GHz (Tyan Thunder K7 motherboard). > > On i386 libthr limits an application to 128 _concurrent_ threads. So, you > should check the return value from pthread_create() for EAGAIN, in which case > you should retry again. > > > On ia64 I get the following with libthr (libkse is not completely > > ported yet): > > > > % ./foo2 1000 > > [very long list of random "bar #" > > : > > bar 999 > > bar 226 > > bar 244 > > Thread (_thread_initial:0) already on mutexq > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > Great! I've been waiting for this message to appear for some time. Do you have a > backtrace by any chance? If not, that's Ok, even without it the program is > simple enough that I know where to start looking. > > > Note that I don't have any of David's signal code patches applied. > > Any unbreaking of signals in the kernel would definitely help libthr. David's changes are mostly kse related. > > Cheers. > -- > Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc > mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 > mtm@FreeBSD.Org| FreeBSD - The Power To Serve > _______________________________________________ > 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 Thu Jun 26 18:24:58 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2603537B401 for ; Thu, 26 Jun 2003 18:24:58 -0700 (PDT) Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F5C43F93 for ; Thu, 26 Jun 2003 18:24:57 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.140.205]) by pop017.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net>; Thu, 26 Jun 2003 20:24:56 -0500 Date: Thu, 26 Jun 2003 21:24:55 -0400 From: Mike Makonnen To: Marcel Moolenaar In-Reply-To: <20030627003922.GA38103@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [138.88.140.205] at Thu, 26 Jun 2003 20:24:56 -0500 Message-Id: <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 01:24:58 -0000 On Thu, 26 Jun 2003 17:39:22 -0700 Marcel Moolenaar wrote: > On Thu, Jun 26, 2003 at 08:21:54PM -0400, Mike Makonnen wrote: > > > > > > % ./foo2 1000 > > > [very long list of random "bar #" > > > : > > > bar 999 > > > bar 226 > > > bar 244 > > > Thread (_thread_initial:0) already on mutexq > > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > > > Great! I've been waiting for this message to appear for some time. Do you > > have a backtrace by any chance? > > gdb(1) hasn't been ported yet, so no. > BTW: The thread is not always _thread_initial... hmm.. ok if it's not always thread initial, that's gonna make it a bit harder. Can you try this quick hack: http://people.freebsd.org/~mtm/patches/libthr.sigblock.diff It simply blocks all signals while libthr holds a lock. I'd be interested in knowing whether you still get the same errors. > > > Note that I don't have any of David's signal code patches applied. > > > > Any unbreaking of signals in the kernel would definitely help libthr. > > If it's expected to make a difference, I can grab them and try again. > Just say the word... If you have the time/inclination. I'll grab them as well and see what happens. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 19:17:07 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3AAE37B401 for ; Thu, 26 Jun 2003 19:17:07 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABC6D43FE9 for ; Thu, 26 Jun 2003 19:17:06 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R2H6DZ020811; Thu, 26 Jun 2003 19:17:06 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R2H6hn038511; Thu, 26 Jun 2003 19:17:06 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5R2H6LO038510; Thu, 26 Jun 2003 19:17:06 -0700 (PDT) (envelope-from marcel) Date: Thu, 26 Jun 2003 19:17:06 -0700 From: Marcel Moolenaar To: Mike Makonnen Message-ID: <20030627021706.GA38490@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> User-Agent: Mutt/1.5.4i cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 02:17:08 -0000 On Thu, Jun 26, 2003 at 09:24:55PM -0400, Mike Makonnen wrote: > > > > gdb(1) hasn't been ported yet, so no. > > BTW: The thread is not always _thread_initial... > > hmm.. ok if it's not always thread initial, that's gonna make it a bit harder. > Can you try this quick hack: > http://people.freebsd.org/~mtm/patches/libthr.sigblock.diff No improvement: : bar 98 bar 99 Thread (GC:2) already on mutexq Fatal error 'Illegal call from signal handler' at line 1347 in file /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort (core dumped) Is this something you really need a stacktrace of? > > If it's expected to make a difference, I can grab them and try again. > > Just say the word... > > If you have the time/inclination. I'll grab them as well and see what happens. I'll try that this weekend then. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 20:06:00 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6674937B401; Thu, 26 Jun 2003 20:06:00 -0700 (PDT) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F7B844008; Thu, 26 Jun 2003 20:05:59 -0700 (PDT) (envelope-from kutulu@kutulu.org) Received: by basement.kutulu.org (Postfix, from userid 1001) id 20E1AA9D8; Thu, 26 Jun 2003 23:06:01 -0400 (EDT) Date: Thu, 26 Jun 2003 23:06:00 -0400 From: Michael Edenfield To: threads@freebsd.org, current@freebsd.org Message-ID: <20030627030600.GA13006@basement.kutulu.org> Mail-Followup-To: threads@freebsd.org, current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F User-Agent: Mutt/1.5.4i Subject: no more unkillable kse threads. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 03:06:00 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just an FYI: After doing a rebuild of my kernel/world over night I can no longer=20 reproduce the unkillable 'ksetest' program problem. I didn't apply=20 any of the signal handling patches or anything special, so I guess=20 something was just flukey with my setup. Thanks! --Mike --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE++7SXCczNhKRsh48RAoByAKCJf7AZ61MT2JeQpqqChMRHqGX0sQCfRFGj k+oCBjwduVOmhNQBvNr4rFc= =7VkB -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 21:26:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0135B37B401 for ; Thu, 26 Jun 2003 21:26:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41DBC43FCB for ; Thu, 26 Jun 2003 21:26:35 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5R4QXXh025279; Fri, 27 Jun 2003 00:26:33 -0400 (EDT) Date: Fri, 27 Jun 2003 00:26:33 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: Marcel Moolenaar Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 04:26:36 -0000 On Thu, 26 Jun 2003, Mike Makonnen wrote: > On Thu, 26 Jun 2003 17:39:22 -0700 > Marcel Moolenaar wrote: > > > On Thu, Jun 26, 2003 at 08:21:54PM -0400, Mike Makonnen wrote: > > > > > > > > % ./foo2 1000 > > > > [very long list of random "bar #" > > > > : > > > > bar 999 > > > > bar 226 > > > > bar 244 > > > > Thread (_thread_initial:0) already on mutexq > > > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > > > > > Great! I've been waiting for this message to appear for some time. Do you > > > have a backtrace by any chance? > > > > gdb(1) hasn't been ported yet, so no. > > BTW: The thread is not always _thread_initial... > > hmm.. ok if it's not always thread initial, that's gonna make it a bit harder. > Can you try this quick hack: > http://people.freebsd.org/~mtm/patches/libthr.sigblock.diff > > It simply blocks all signals while libthr holds a lock. I'd be > interested in knowing whether you still get the same errors. I haven't looked at libthr much, so perhaps this doesn't apply... Signal handling and locks (low-level, CV, mutex, etc) are somewhat difficult to deal with, especially when there are mutexes in libc that the application doesn't even see. In general, signals can't be deferred around big locks (mutexes, CVs, rwlocks, etc), but may be around low-level locks (which is what I think your patch is doing). It is valid for an application to have a thread blocked in pthread_mutex_lock(), pthread_cond_timedwait(), etc, receive a signal. The signal handler should run, but those functions should not return EINTR; they should continue blocking when the handler returns. It is also valid for a thread to be blocked in fwrite() (or some other libc function that has locking) and receive a signal. In either case, you also have to handle the the thread _not_ returning normally; it could [sig]longjmp() or setcontext() out of the locked area. So if you are keeping any internal queues for mutexes, CVs, etc, you have to ensure the thread is removed from the queue before the signal handler is invoked, and then reinsert the thread back into the queue if the signal handler returns normally. The error message that Marcel posted (already on mutexq) reminds me of similar problems long ago in libc_r. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 23:35:15 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07EB937B401; Thu, 26 Jun 2003 23:35:15 -0700 (PDT) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A72B43FE1; Thu, 26 Jun 2003 23:35:14 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.140.205]) by out006.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 01:35:13 -0500 Date: Fri, 27 Jun 2003 02:35:12 -0400 From: Mike Makonnen To: deischen@freebsd.org In-Reply-To: References: <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out006.verizon.net from [138.88.140.205] at Fri, 27 Jun 2003 01:35:12 -0500 Message-Id: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 06:35:15 -0000 On Fri, 27 Jun 2003 00:26:33 -0400 (EDT) Daniel Eischen wrote: > > Signal handling and locks (low-level, CV, mutex, etc) are > somewhat difficult to deal with, especially when there are > mutexes in libc that the application doesn't even see. > Heh. no kidding :-) > In general, signals can't be deferred around big locks > (mutexes, CVs, rwlocks, etc), but may be around low-level > locks (which is what I think your patch is doing). Correct. It wasn't designed to solve Marcel's problem. It was to narrow the possible culprits down. > It is valid for an application to have a thread blocked > in pthread_mutex_lock(), pthread_cond_timedwait(), etc, > receive a signal. The signal handler should run, but > those functions should not return EINTR; they should > continue blocking when the handler returns. > > It is also valid for a thread to be blocked in fwrite() > (or some other libc function that has locking) and > receive a signal. Yes, this is my understanding as well-- unless they attempt to use a pthreads facility or call non-async safe libc routines from signal handlers, in which case all bets are off. I believe the pthread_cancel() family of functions is the only one that's guaranteed to be async safe. > In either case, you also have to handle the the thread > _not_ returning normally; it could [sig]longjmp() or > setcontext() out of the locked area. So if you are keeping > any internal queues for mutexes, CVs, etc, you have > to ensure the thread is removed from the queue before > the signal handler is invoked, and then reinsert the > thread back into the queue if the signal handler > returns normally. This is what I don't understand very well. Is it necessary in a 1:1 library? I can understand this sort of behind-the-scenes manipultaion in lic_r or libkse, where the uts might need to be protected from those kinds of situations. But for libthr, where all scheduling and signaling is taken care of in the kernel I would be inclined to say "all bets are off." As I wrote earlier, it's my understanding that the only pthreads routines you can rely on to be async safe are pthread_cancel() and friends. I admit I could be grossly misunderstanding the situation, in which case I would really appreciate a clarification. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 23:41:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB6D37B401 for ; Thu, 26 Jun 2003 23:41:31 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44A2F43FE0 for ; Thu, 26 Jun 2003 23:41:30 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.140.205]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 01:41:29 -0500 Date: Fri, 27 Jun 2003 02:41:28 -0400 From: Mike Makonnen To: Marcel Moolenaar In-Reply-To: <20030627021706.GA38490@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> <20030627021706.GA38490@dhcp01.pn.xcllnt.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [138.88.140.205] at Fri, 27 Jun 2003 01:41:28 -0500 Message-Id: <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 06:41:31 -0000 On Thu, 26 Jun 2003 19:17:06 -0700 Marcel Moolenaar wrote: > No improvement: > > : > bar 98 > bar 99 > Thread (GC:2) already on mutexq > Fatal error 'Illegal call from signal handler' at line 1347 in file > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort (core > dumped) > > Is this something you really need a stacktrace of? No. I was only interested in seeing if this caused the "Illigal call...." to go away. > > > If it's expected to make a difference, I can grab them and try again. > > > Just say the word... > > > > If you have the time/inclination. I'll grab them as well and see what > > happens. > > I'll try that this weekend then. I have corresponded briefly with jdp, and from what he tells me there's something really wrong with signal handling in the kernel. I'm inclined to believe him because I've seen some really strange lockups that I can't seem to pin on libthr (even though it still needs some work). I welcome any attempt; however unrelated to libthr, to clean up signal handling there. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Thu Jun 26 23:54:03 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C00537B401 for ; Thu, 26 Jun 2003 23:54:03 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D41E43FF5 for ; Thu, 26 Jun 2003 23:54:02 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.140.205]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627065401.BMRW20810.pop015.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 01:54:01 -0500 Date: Fri, 27 Jun 2003 02:54:00 -0400 From: Mike Makonnen To: Mike Makonnen In-Reply-To: <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> <20030627021706.GA38490@dhcp01.pn.xcllnt.net> <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.140.205] at Fri, 27 Jun 2003 01:54:01 -0500 Message-Id: <20030627065401.BMRW20810.pop015.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 06:54:03 -0000 On Fri, 27 Jun 2003 02:41:28 -0400 Mike Makonnen wrote: > On Thu, 26 Jun 2003 19:17:06 -0700 > Marcel Moolenaar wrote: > > > > No improvement: > > > > : > > bar 98 > > bar 99 > > Thread (GC:2) already on mutexq > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort (core > > dumped) > > > > Is this something you really need a stacktrace of? > > No. I was only interested in seeing if this caused the "Illigal call...." to > go away. err... that's not what I meant to say. What I meant was: Yes it would be nice to get a trace, but don't bother if you have to jump through hoops to do it. The patch I sent you was not actually meant to solve your problem. I wanted to narrow down the search for the culprit. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 00:02:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD3337B401 for ; Fri, 27 Jun 2003 00:02:25 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE7E943F3F for ; Fri, 27 Jun 2003 00:02:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R72ODZ022074; Fri, 27 Jun 2003 00:02:24 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R72Ohn041304; Fri, 27 Jun 2003 00:02:24 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5R72Ne8041303; Fri, 27 Jun 2003 00:02:23 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Jun 2003 00:02:23 -0700 From: Marcel Moolenaar To: Mike Makonnen Message-ID: <20030627070223.GA41236@dhcp01.pn.xcllnt.net> References: <3EFB2E12.3080504@intalio.com> <20030626203624.GA37317@dhcp01.pn.xcllnt.net> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> <20030627021706.GA38490@dhcp01.pn.xcllnt.net> <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627064129.DZPG3199.pop016.verizon.net@kokeb.ambesa.net> User-Agent: Mutt/1.5.4i cc: freebsd-threads@FreeBSD.org Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 07:02:26 -0000 On Fri, Jun 27, 2003 at 02:41:28AM -0400, Mike Makonnen wrote: > > Thread (GC:2) already on mutexq > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort (core > > dumped) > > > > Is this something you really need a stacktrace of? > > No. I was only interested in seeing if this caused the "Illigal call...." > to go away. Ok, that fortunate. If it was important, I would have to see if it would change its relative priority and possibly reschedule my todo list. Arun@ has done a lot on that front, but it needs more work to be usable. The more complex the userland problems the more we need a debugger. > I have corresponded briefly with jdp, and from what he tells me there's > something really wrong with signal handling in the kernel. I'm inclined to > believe him because I've seen some really strange lockups that I can't seem to > pin on libthr (even though it still needs some work). I welcome any attempt; > however unrelated to libthr, to clean up signal handling there. I'll keep it in mind. I probably don't have the time to look for anything weird, but I might just happen to run into something... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 00:18:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D0F137B401; Fri, 27 Jun 2003 00:18:31 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9177943FF5; Fri, 27 Jun 2003 00:18:28 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5R7IPiP001596; Fri, 27 Jun 2003 00:18:25 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5R7IOrl001595; Fri, 27 Jun 2003 00:18:24 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 27 Jun 2003 00:18:24 -0700 From: David Schultz To: Alexey Zelkin Message-ID: <20030627071824.GA1579@HAL9000.homeunix.com> Mail-Followup-To: Alexey Zelkin , David Xu , threads@freebsd.org References: <20030625192326.A15424@phantom.cris.net> <004d01c33b7f$ede4dc30$f001a8c0@davidw2k> <20030627005225.A25700@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627005225.A25700@phantom.cris.net> cc: threads@FreeBSD.ORG cc: David Xu Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 07:18:31 -0000 On Fri, Jun 27, 2003, Alexey Zelkin wrote: > hi, > > On Thu, Jun 26, 2003 at 09:11:32AM +0800, David Xu wrote: > > > > On Wed, Jun 25, 2003 at 09:55:21AM -0400, Daniel Eischen wrote: > > > > On Wed, 25 Jun 2003, Alexey Zelkin wrote: > > > > > > > > > hi, > > > > > ... > > > > > Looks like signals are still not really working in libkse. > > > > > > > > David Xu is revamping signal handling (it also involves > > > > some kernel changes). Very alpha patches are at: > > > > > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > > > > > > They are not yet completely working, but might help. > > > > > > Cool! It really helped. At least visible behaviour is same to libc_r. > > > > > > > Your test is appreciated. I have updated the patches again, > > they have past signal test suites included in libpthread. > > Can you test these new patches again ? > > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz > > It just works. Comparing to first signal patches it behaves even > better. I did not see any random process lockups. Build & all TCK's > VM tests passed. That's great to hear. Does this mean there will soon be a binary distribution of JDK 1.4 for FreeBSD? From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 00:56:08 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA04837B401; Fri, 27 Jun 2003 00:56:08 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C26343FE9; Fri, 27 Jun 2003 00:56:08 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R7u7DZ022323; Fri, 27 Jun 2003 00:56:07 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R7u7hn042238; Fri, 27 Jun 2003 00:56:07 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5R7u7SZ042237; Fri, 27 Jun 2003 00:56:07 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Jun 2003 00:56:07 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org, ru@FreeBSD.org Message-ID: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 07:56:09 -0000 [Ruslan added for his insights] Ok, I decided to obsolete libc_r on ia64 so that I can de-pessimize the setjmp/longjmp code some time before 5.2 and have sufficient time to deal with problems due to not having libc_r. One thing we probably want to do is create compatibility links from libc_r* to libthr* or libkse*. At this time I libthr is tested on ia64, so I opt to have libc_r linked to libthr. What's the best way to do that, so that it can be used for other platforms in due time? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 01:06:00 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C2F37B401 for ; Fri, 27 Jun 2003 01:06:00 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30B5F43FBD for ; Fri, 27 Jun 2003 01:05:55 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h5R85oVd049106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2003 11:05:50 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h5R85oiW049101; Fri, 27 Jun 2003 11:05:50 +0300 (EEST) (envelope-from ru) Date: Fri, 27 Jun 2003 11:05:50 +0300 From: Ruslan Ermilov To: Marcel Moolenaar Message-ID: <20030627080550.GA48342@sunbay.com> References: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 08:06:00 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Funny thing: reading your commit mail, and right after that receiving this message. :-) On Fri, Jun 27, 2003 at 12:56:07AM -0700, Marcel Moolenaar wrote: > [Ruslan added for his insights] >=20 > Ok, >=20 > I decided to obsolete libc_r on ia64 so that I can de-pessimize the > setjmp/longjmp code some time before 5.2 and have sufficient time to > deal with problems due to not having libc_r. >=20 > One thing we probably want to do is create compatibility links from > libc_r* to libthr* or libkse*. At this time I libthr is tested on > ia64, so I opt to have libc_r linked to libthr. What's the best way > to do that, so that it can be used for other platforms in due time? >=20 First off, symlinking won't help old binaries that were linked dynamically with libc_r.so.X, but you're supposed to well know that already. :-) So, the only useful option that is left is to symlink the static and dymanic libraries (.a and .so, but not .so.X), and this can be done in libc_r/Makefile using SYMLINKS (for MACHINE_ARCH of ia64 only). Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE++/rdUkv4P6juNwoRAkE4AJ9khMzeLqQzmvc+L7Aupmsod2d3KQCbBacH 1U0mZ+eWtRt4/gAbT9QjCRw= =Hgzp -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 01:52:00 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74C3737B401; Fri, 27 Jun 2003 01:52:00 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FE1B43FE3; Fri, 27 Jun 2003 01:51:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R8pwDZ022586; Fri, 27 Jun 2003 01:51:58 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5R8pwhn043070; Fri, 27 Jun 2003 01:51:58 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5R8pwbG043069; Fri, 27 Jun 2003 01:51:58 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Jun 2003 01:51:58 -0700 From: Marcel Moolenaar To: Ruslan Ermilov Message-ID: <20030627085158.GA42350@dhcp01.pn.xcllnt.net> References: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> <20030627080550.GA48342@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627080550.GA48342@sunbay.com> User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 08:52:00 -0000 On Fri, Jun 27, 2003 at 11:05:50AM +0300, Ruslan Ermilov wrote: > Funny thing: reading your commit mail, and right after that > receiving this message. :-) > > On Fri, Jun 27, 2003 at 12:56:07AM -0700, Marcel Moolenaar wrote: > > [Ruslan added for his insights] > > > > Ok, > > > > I decided to obsolete libc_r on ia64 so that I can de-pessimize the > > setjmp/longjmp code some time before 5.2 and have sufficient time to > > deal with problems due to not having libc_r. > > > > One thing we probably want to do is create compatibility links from > > libc_r* to libthr* or libkse*. At this time I libthr is tested on > > ia64, so I opt to have libc_r linked to libthr. What's the best way > > to do that, so that it can be used for other platforms in due time? > > > First off, symlinking won't help old binaries that were linked > dynamically with libc_r.so.X, but you're supposed to well know > that already. :-) Correct. I'm not worried about compatibility with previous releases and the likes, because ia64 is still tier 2. I want "cc -pthread" to work. > So, the only useful option that is left is to symlink the static > and dymanic libraries (.a and .so, but not .so.X), and this can > be done in libc_r/Makefile using SYMLINKS (for MACHINE_ARCH of > ia64 only). In libc_r/Makefile? Aren't we going to build libc_r first and then overwrite the intalled libc_r with symlinks? What about: Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libthr/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile 23 May 2003 09:48:20 -0000 1.3 +++ Makefile 27 Jun 2003 08:49:54 -0000 @@ -10,6 +10,13 @@ LIB=thr SHLIB_MAJOR= 1 DEBUG_FLAGS=-g + +.if ${MACHINE_ARCH} == "ia64" +SYMLINKS= libthr.a ${SHLIBDIR}/libc_r.a \ + libthr.so ${SHLIBDIR}/libc_r.so \ + libthr_p.a ${SHLIBDIR}/libc_r_p.a +.endif + CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE CFLAGS+=-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ -I${.CURDIR}/../../include -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 02:10:21 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C8B37B401; Fri, 27 Jun 2003 02:10:21 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF29443FD7; Fri, 27 Jun 2003 02:10:14 -0700 (PDT) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h5RCE3np000446; Fri, 27 Jun 2003 12:14:04 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h5R9Hc4N028948; Fri, 27 Jun 2003 12:17:38 +0300 (EEST) (envelope-from phantom) Date: Fri, 27 Jun 2003 12:17:38 +0300 From: Alexey Zelkin To: deischen@freebsd.org Message-ID: <20030627121738.A28850@phantom.cris.net> References: <20030627005225.A25700@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Thu, Jun 26, 2003 at 08:48:21PM -0400 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: threads@freebsd.org cc: David Xu Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 09:10:21 -0000 hi, On Thu, Jun 26, 2003 at 08:48:21PM -0400, Daniel Eischen wrote: > > > > > > Looks like signals are still not really working in libkse. > > > > > > > > > > David Xu is revamping signal handling (it also involves > > > > > some kernel changes). Very alpha patches are at: > > > > > > > > > > http://people.freebsd.org/~davidxu/kse_sig/ > > > > > > > > > > They are not yet completely working, but might help. > > > > > > > > Cool! It really helped. At least visible behaviour is same to libc_r. > > > > > > > > > > Your test is appreciated. I have updated the patches again, > > > they have past signal test suites included in libpthread. > > > Can you test these new patches again ? > > > http://people.freebsd.org/~davidxu/kse_sig/kern.diff > > > http://people.freebsd.org/~davidxu/kse_sig/libpthread.tgz > > > > It just works. Comparing to first signal patches it behaves even > > better. I did not see any random process lockups. Build & all TCK's > > VM tests passed. > > Wow, that's great news. Do you have an SMP system to try the > TCK tests on? Libpthread will automatically create as many > KSEs as you have CPUs. Unfortunatelly no :-( There're a lot of problems with customs in my country with receiving "free" computers and therefore I did not posted entry to wishlist. > Do you have any performance benchmarks so we can compare > against libc_r (or even libthr)? Not yet. Functional changes have more priority for me than benchmarking, sorry. libkse&libthr issues were "maybe need to be fixed" issues :-) > BTW, thanks for taking the time to run these tests :-) From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 03:14:53 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E32837B401 for ; Fri, 27 Jun 2003 03:14:53 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EAB043F3F for ; Fri, 27 Jun 2003 03:14:48 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h5RAEgVd065678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2003 13:14:43 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h5RAEfph065669; Fri, 27 Jun 2003 13:14:41 +0300 (EEST) (envelope-from ru) Date: Fri, 27 Jun 2003 13:14:41 +0300 From: Ruslan Ermilov To: Marcel Moolenaar Message-ID: <20030627101441.GD48342@sunbay.com> References: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> <20030627080550.GA48342@sunbay.com> <20030627085158.GA42350@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline In-Reply-To: <20030627085158.GA42350@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 10:14:53 -0000 --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 27, 2003 at 01:51:58AM -0700, Marcel Moolenaar wrote: > On Fri, Jun 27, 2003 at 11:05:50AM +0300, Ruslan Ermilov wrote: [...] > > So, the only useful option that is left is to symlink the static > > and dymanic libraries (.a and .so, but not .so.X), and this can > > be done in libc_r/Makefile using SYMLINKS (for MACHINE_ARCH of > > ia64 only). >=20 > In libc_r/Makefile? >=20 A typo. I meant libthr/Makefile. > Aren't we going to build libc_r first and then >=20 libthr, that is. You made the same typo. :-) > overwrite the intalled libc_r with symlinks? > What about: >=20 > Index: Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/lib/libthr/Makefile,v > retrieving revision 1.3 > diff -u -r1.3 Makefile > --- Makefile 23 May 2003 09:48:20 -0000 1.3 > +++ Makefile 27 Jun 2003 08:49:54 -0000 > @@ -10,6 +10,13 @@ > LIB=3Dthr > SHLIB_MAJOR=3D 1 > DEBUG_FLAGS=3D-g > + > +.if ${MACHINE_ARCH} =3D=3D "ia64" > +SYMLINKS=3D libthr.a ${SHLIBDIR}/libc_r.a \ > + libthr.so ${SHLIBDIR}/libc_r.so \ > + libthr_p.a ${SHLIBDIR}/libc_r_p.a > +.endif > + > CFLAGS+=3D-DPTHREAD_KERNEL -D_THREAD_SAFE > CFLAGS+=3D-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ > -I${.CURDIR}/../../include >=20 This isn't so easy. You should check NOPIC (that can be set to globally suppress the rtld support) and NOPROFILE. Please see lib/libncuses/Makefile for a working example. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --OZkY3AIuv2LYvjdk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+/BkRUkv4P6juNwoRAik8AKCCrPcE9MjcKfS6DnsNMyc+I/vtRQCeLkSF mMmz7OxIhJrr1Y/oFS37zSc= =a02/ -----END PGP SIGNATURE----- --OZkY3AIuv2LYvjdk-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 04:14:45 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA0D337B401 for ; Fri, 27 Jun 2003 04:14:45 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3EAE43FE3 for ; Fri, 27 Jun 2003 04:14:44 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5RBEhXh021487; Fri, 27 Jun 2003 07:14:43 -0400 (EDT) Date: Fri, 27 Jun 2003 07:14:43 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 11:14:46 -0000 On Fri, 27 Jun 2003, Mike Makonnen wrote: > On Fri, 27 Jun 2003 00:26:33 -0400 (EDT) > Daniel Eischen wrote: > > > > > Signal handling and locks (low-level, CV, mutex, etc) are > > somewhat difficult to deal with, especially when there are > > mutexes in libc that the application doesn't even see. > > > > Heh. no kidding :-) > > > In general, signals can't be deferred around big locks > > (mutexes, CVs, rwlocks, etc), but may be around low-level > > locks (which is what I think your patch is doing). > > Correct. It wasn't designed to solve Marcel's problem. It was to narrow the > possible culprits down. > > > It is valid for an application to have a thread blocked > > in pthread_mutex_lock(), pthread_cond_timedwait(), etc, > > receive a signal. The signal handler should run, but > > those functions should not return EINTR; they should > > continue blocking when the handler returns. > > > > It is also valid for a thread to be blocked in fwrite() > > (or some other libc function that has locking) and > > receive a signal. > > Yes, this is my understanding as well-- unless they attempt to use a pthreads > facility or call non-async safe libc routines from signal handlers, in which > case all bets are off. I believe the pthread_cancel() family of functions is the > only one that's guaranteed to be async safe. > > > > In either case, you also have to handle the the thread > > _not_ returning normally; it could [sig]longjmp() or > > setcontext() out of the locked area. So if you are keeping > > any internal queues for mutexes, CVs, etc, you have > > to ensure the thread is removed from the queue before > > the signal handler is invoked, and then reinsert the > > thread back into the queue if the signal handler > > returns normally. > > This is what I don't understand very well. Is it necessary in a 1:1 library? I > can understand this sort of behind-the-scenes manipultaion in lic_r or libkse, > where the uts might need to be protected from those kinds of situations. But for > libthr, where all scheduling and signaling is taken care of in the kernel I > would be inclined to say "all bets are off." As I wrote earlier, it's my > understanding that the only pthreads routines you can rely on to be async safe > are pthread_cancel() and friends. > > I admit I could be grossly misunderstanding the situation, in which case I > would really appreciate a clarification. To answer your first question, yes, I think it's necessary. Here's an example: void sigalarmhandler(int sig) { longjmp(env, 1); } int somenslookup(...) { ... alarm(5); /* Wait a maximum of 5 seconds. */ if (setjmp(env) == 0) { nsdispatch(...); return (0); } return (-1); } Now perhaps this isn't the best example; imagine using something that used malloc()/free() or any one of the other locked libc functions. There is also the use of application level-locks which should work similarly, but by using libc example I avoid any argument about "the application shouldn't be doing that" :-) It's also possible that the thread calls the same set of libc functions again, and if it isn't removed from the internal mutex queue, then you'd get the exact error message Marcel was seeing (already on mutexq). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 04:21:40 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AD437B401; Fri, 27 Jun 2003 04:21:40 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78B5F44005; Fri, 27 Jun 2003 04:21:39 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5RBLcXh022434; Fri, 27 Jun 2003 07:21:38 -0400 (EDT) Date: Fri, 27 Jun 2003 07:21:38 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030627085158.GA42350@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Ruslan Ermilov Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 11:21:40 -0000 On Fri, 27 Jun 2003, Marcel Moolenaar wrote: > On Fri, Jun 27, 2003 at 11:05:50AM +0300, Ruslan Ermilov wrote: > > Funny thing: reading your commit mail, and right after that > > receiving this message. :-) > > > > On Fri, Jun 27, 2003 at 12:56:07AM -0700, Marcel Moolenaar wrote: > > > [Ruslan added for his insights] > > > > > > Ok, > > > > > > I decided to obsolete libc_r on ia64 so that I can de-pessimize the > > > setjmp/longjmp code some time before 5.2 and have sufficient time to > > > deal with problems due to not having libc_r. > > > > > > One thing we probably want to do is create compatibility links from > > > libc_r* to libthr* or libkse*. At this time I libthr is tested on > > > ia64, so I opt to have libc_r linked to libthr. What's the best way > > > to do that, so that it can be used for other platforms in due time? > > > > > First off, symlinking won't help old binaries that were linked > > dynamically with libc_r.so.X, but you're supposed to well know > > that already. :-) > > Correct. I'm not worried about compatibility with previous releases > and the likes, because ia64 is still tier 2. I want "cc -pthread" > to work. -pthread is obsoleted in -current. I'm surprised that it hasn't been nuked yet. There hasn't been a need for it in well over 2 years. Just use -lpthread (-lkse) or -lthr. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 04:26:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40B9137B401; Fri, 27 Jun 2003 04:26:26 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EF2243FDF; Fri, 27 Jun 2003 04:26:23 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5RBQMXh023137; Fri, 27 Jun 2003 07:26:22 -0400 (EDT) Date: Fri, 27 Jun 2003 07:26:21 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alexey Zelkin In-Reply-To: <20030627121738.A28850@phantom.cris.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: libkse & jdk14: signals(?) breakage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 11:26:26 -0000 On Fri, 27 Jun 2003, Alexey Zelkin wrote: > > On Thu, Jun 26, 2003 at 08:48:21PM -0400, Daniel Eischen wrote: > > > > Wow, that's great news. Do you have an SMP system to try the > > TCK tests on? Libpthread will automatically create as many > > KSEs as you have CPUs. > > Unfortunatelly no :-( There're a lot of problems with customs in my > country with receiving "free" computers and therefore I did not posted > entry to wishlist. Perhaps you could "buy" one for $1.00(US)? Or the FreeBSD Foundation can send you the money to "buy" one of their own donated computers? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 04:39:45 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6616C37B401; Fri, 27 Jun 2003 04:39:45 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF99C43FE5; Fri, 27 Jun 2003 04:39:40 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h5RBdaVd074977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2003 14:39:36 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h5RBdaNq074972; Fri, 27 Jun 2003 14:39:36 +0300 (EEST) (envelope-from ru) Date: Fri, 27 Jun 2003 14:39:36 +0300 From: Ruslan Ermilov To: Daniel Eischen Message-ID: <20030627113936.GA68781@sunbay.com> References: <20030627085158.GA42350@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@FreeBSD.org cc: Marcel Moolenaar Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 11:39:45 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 27, 2003 at 07:21:38AM -0400, Daniel Eischen wrote: > On Fri, 27 Jun 2003, Marcel Moolenaar wrote: >=20 > > On Fri, Jun 27, 2003 at 11:05:50AM +0300, Ruslan Ermilov wrote: > > > Funny thing: reading your commit mail, and right after that > > > receiving this message. :-) > > >=20 > > > On Fri, Jun 27, 2003 at 12:56:07AM -0700, Marcel Moolenaar wrote: > > > > [Ruslan added for his insights] > > > >=20 > > > > Ok, > > > >=20 > > > > I decided to obsolete libc_r on ia64 so that I can de-pessimize the > > > > setjmp/longjmp code some time before 5.2 and have sufficient time to > > > > deal with problems due to not having libc_r. > > > >=20 > > > > One thing we probably want to do is create compatibility links from > > > > libc_r* to libthr* or libkse*. At this time I libthr is tested on > > > > ia64, so I opt to have libc_r linked to libthr. What's the best way > > > > to do that, so that it can be used for other platforms in due time? > > > >=20 > > > First off, symlinking won't help old binaries that were linked > > > dynamically with libc_r.so.X, but you're supposed to well know > > > that already. :-) > >=20 > > Correct. I'm not worried about compatibility with previous releases > > and the likes, because ia64 is still tier 2. I want "cc -pthread" > > to work. >=20 > -pthread is obsoleted in -current. I'm surprised that it > hasn't been nuked yet. There hasn't been a need for it > in well over 2 years. Just use -lpthread (-lkse) or -lthr. >=20 Oh, I thought that the intent was to be able to write -lc_r and have the linker pick up another (modern) threaded library. If that is just to support -pthread, I also think that the latter should just be nuked. It is similarly news to me that -pthread is still alive; I thought we killed it months ago. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+/Cz4Ukv4P6juNwoRAv8pAJ43pCj4JW8i9TZwHaqXFCFBTU95QACfe5a8 20qfnz+k0VNxhypj+8+9Meo= =WD+m -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 06:57:02 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BD8E37B401; Fri, 27 Jun 2003 06:57:02 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A90D43FEA; Fri, 27 Jun 2003 06:57:01 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5RDv1DZ024207; Fri, 27 Jun 2003 06:57:01 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5RDv0hn044347; Fri, 27 Jun 2003 06:57:00 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5RDv0ZQ044346; Fri, 27 Jun 2003 06:57:00 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Jun 2003 06:57:00 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030627135700.GA43189@dhcp01.pn.xcllnt.net> References: <20030627085158.GA42350@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org cc: Ruslan Ermilov Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 13:57:02 -0000 On Fri, Jun 27, 2003 at 07:21:38AM -0400, Daniel Eischen wrote: > > > > Correct. I'm not worried about compatibility with previous releases > > and the likes, because ia64 is still tier 2. I want "cc -pthread" > > to work. > > -pthread is obsoleted in -current. I'm surprised that it > hasn't been nuked yet. There hasn't been a need for it > in well over 2 years. Just use -lpthread (-lkse) or -lthr. Ah, ok. We still have some hardcodings to -lc_r, so if nothing else, I avoid breakages causes by not having -lc_r (or an old one). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 07:15:07 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A205937B401; Fri, 27 Jun 2003 07:15:07 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D16BD43FE9; Fri, 27 Jun 2003 07:15:06 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5REF6DZ024278; Fri, 27 Jun 2003 07:15:06 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5REF6hn044434; Fri, 27 Jun 2003 07:15:06 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5REF6tb044433; Fri, 27 Jun 2003 07:15:06 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Jun 2003 07:15:06 -0700 From: Marcel Moolenaar To: Ruslan Ermilov Message-ID: <20030627141506.GB43189@dhcp01.pn.xcllnt.net> References: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> <20030627080550.GA48342@sunbay.com> <20030627085158.GA42350@dhcp01.pn.xcllnt.net> <20030627101441.GD48342@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627101441.GD48342@sunbay.com> User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 14:15:08 -0000 On Fri, Jun 27, 2003 at 01:14:41PM +0300, Ruslan Ermilov wrote: *snip* > This isn't so easy. You should check NOPIC (that can be > set to globally suppress the rtld support) and NOPROFILE. > Please see lib/libncuses/Makefile for a working example. Good call. How's this: Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libthr/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile 23 May 2003 09:48:20 -0000 1.3 +++ Makefile 27 Jun 2003 14:11:33 -0000 @@ -26,4 +26,16 @@ .include "${.CURDIR}/sys/Makefile.inc" .include "${.CURDIR}/arch/${MACHINE_ARCH}/Makefile.inc" +.if ${MACHINE_ARCH} == "ia64" +.if !defined(NOLIBC_R) +SYMLINKS+=libthr.a ${LIBDIR}/libc_r.a +.if !defined(NOPIC) +SYMLINKS+=libthr.so ${SHLIBDIR}/libc_r.so +.endif +.if !defined(NOPROFILE) +SYMLINKS+=libthr_p.a ${LIBDIR}/libc_r_p.a +.endif +.endif +.endif + .include -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 07:47:43 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFCC637B401 for ; Fri, 27 Jun 2003 07:47:43 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E232043FBD for ; Fri, 27 Jun 2003 07:47:37 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h5RElUVd096937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2003 17:47:31 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h5RElSed096926; Fri, 27 Jun 2003 17:47:28 +0300 (EEST) (envelope-from ru) Date: Fri, 27 Jun 2003 17:47:28 +0300 From: Ruslan Ermilov To: Marcel Moolenaar Message-ID: <20030627144728.GB88746@sunbay.com> References: <20030627075607.GA42198@dhcp01.pn.xcllnt.net> <20030627080550.GA48342@sunbay.com> <20030627085158.GA42350@dhcp01.pn.xcllnt.net> <20030627101441.GD48342@sunbay.com> <20030627141506.GB43189@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline In-Reply-To: <20030627141506.GB43189@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: Obsoleting libc_r: How to create compat links X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 14:47:44 -0000 --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 27, 2003 at 07:15:06AM -0700, Marcel Moolenaar wrote: > How's this: >=20 > Index: Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/lib/libthr/Makefile,v > retrieving revision 1.3 > diff -u -r1.3 Makefile > --- Makefile 23 May 2003 09:48:20 -0000 1.3 > +++ Makefile 27 Jun 2003 14:11:33 -0000 > @@ -26,4 +26,16 @@ > .include "${.CURDIR}/sys/Makefile.inc" > .include "${.CURDIR}/arch/${MACHINE_ARCH}/Makefile.inc" > =20 > +.if ${MACHINE_ARCH} =3D=3D "ia64" > +.if !defined(NOLIBC_R) > +SYMLINKS+=3Dlibthr.a ${LIBDIR}/libc_r.a > +.if !defined(NOPIC) > +SYMLINKS+=3Dlibthr.so ${SHLIBDIR}/libc_r.so > +.endif > +.if !defined(NOPROFILE) > +SYMLINKS+=3Dlibthr_p.a ${LIBDIR}/libc_r_p.a > +.endif > +.endif > +.endif > + > .include >=20 Looks OK, except that I'd swap the NOLIBC_R and MACHINE_ARCH checks, as the former is more specific to the subject. Sorry in advance for nitpicking. ;) Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+/Fj/Ukv4P6juNwoRAr3bAJ9lvC9bF14WFYI5+Wce3OpFp6MdBwCfS9rd 15ZsiZW9b+zeC8s3nwRLEvE= =8d1J -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 08:26:40 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 442FE37B404 for ; Fri, 27 Jun 2003 08:26:40 -0700 (PDT) Received: from basement.kutulu.org (pcp03610121pcs.longhl01.md.comcast.net [68.49.239.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37DB943F93 for ; Fri, 27 Jun 2003 08:26:39 -0700 (PDT) (envelope-from kutulu@kutulu.org) Received: by basement.kutulu.org (Postfix, from userid 1001) id 17208AA81; Fri, 27 Jun 2003 11:26:37 -0400 (EDT) Date: Fri, 27 Jun 2003 11:26:37 -0400 From: Michael Edenfield To: threads@freebsd.org Message-ID: <20030627152637.GA780@basement.kutulu.org> Mail-Followup-To: threads@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline X-Mailer: Mutt http://www.mutt.org/ X-Accept-Language: en X-PGP-Key: http://www.kutulu.org/pgp/kutulu.asc X-PGP-Fingerprint: 1CE0 3C31 7013 D529 406D 37DC 09CC CD84 A46C 878F User-Agent: Mutt/1.5.4i Subject: the *other* kse test app not working... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 15:26:40 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The "ksetest" app in the KSE test suite appears to be working for me,=20 but the "rr" program is causing a reproduceable panic. I have two=20 crash dumps from this if anyone's interested. The panic is happening,=20 if I'm teading this right, in mi_switch. The program itself prints=20 out three "thread_start" messages and some fraction of kse_create()=20 when page faults. #5 0xc02717c8 in calltrap () at {standard input}:96 #6 0xc018561f in mi_switch () at /usr/src/sys/kern/kern_synch.c:525 #7 0xc01687b3 in ithread_loop (arg=3D0xc0a08c00) at=20 /usr/src/sys/kern/kern_intr.c:557 520 if (td->td_proc->p_flag & P_SA) 521 thread_switchout(td); 522 sched_switchout(td); 523 524 #if !defined(__alpha__) && !defined(__powerpc__)=20 525 newtd =3D choosethread(); 526 if (td !=3D newtd) 527 cpu_switch(td, newtd); /* SHAZAM!! */ 528 #ifdef SWTCH_OPTIM_STATS 529 else --Mike --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+/GIsCczNhKRsh48RAhtoAKC7sNg5Gly5GxDfGLehbLoX9jneWACfUES2 QW6gWscxvwwImUCRJqBif0E= =nWis -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 08:59:56 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8617A37B401 for ; Fri, 27 Jun 2003 08:59:56 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 157E943FE1 for ; Fri, 27 Jun 2003 08:59:50 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h5RFxcPM018174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Jun 2003 08:59:38 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h5RFxaQT043908; Fri, 27 Jun 2003 08:59:36 -0700 (PDT) (envelope-from jdp) Date: Fri, 27 Jun 2003 08:59:36 -0700 (PDT) Message-Id: <200306271559.h5RFxaQT043908@strings.polstra.com> To: threads@freebsd.org From: John Polstra In-Reply-To: <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> References: <3EFB2E12.3080504@intalio.com> <20030627002155.UEBC11703.pop018.verizon.net@kokeb.ambesa.net> <20030627003922.GA38103@dhcp01.pn.xcllnt.net> <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.478742, version=0.11.2 Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 15:59:56 -0000 In article <20030627012456.YLSF27254.pop017.verizon.net@kokeb.ambesa.net>, Mike Makonnen wrote: > On Thu, 26 Jun 2003 17:39:22 -0700 > Marcel Moolenaar wrote: > > On Thu, Jun 26, 2003 at 08:21:54PM -0400, Mike Makonnen wrote: > > > > Thread (_thread_initial:0) already on mutexq > > > > Fatal error 'Illegal call from signal handler' at line 1347 in file > > > > /nfs/freebsd/5.x/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > > > > > Great! I've been waiting for this message to appear for some time. Do you > > > have a backtrace by any chance? > > > > gdb(1) hasn't been ported yet, so no. > > BTW: The thread is not always _thread_initial... > > hmm.. ok if it's not always thread initial, that's gonna make it a bit harder. I saw it happen to libthr's "GC" thread yesterday: Thread (GC:3) already on mutexq Fatal error 'Illegal call from signal handler' at line 1347 in file /a/src/lib/libthr/thread/thr_mutex.c (errno = 35) John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 15:42:30 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B24BE37B401; Fri, 27 Jun 2003 15:42:30 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C566943FDD; Fri, 27 Jun 2003 15:42:29 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([141.156.32.244]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 17:42:28 -0500 Date: Fri, 27 Jun 2003 18:42:28 -0400 From: Mike Makonnen To: deischen@freebsd.org In-Reply-To: References: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [141.156.32.244] at Fri, 27 Jun 2003 17:42:28 -0500 Message-Id: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 22:42:31 -0000 On Fri, 27 Jun 2003 07:14:43 -0400 (EDT) Daniel Eischen wrote: > > To answer your first question, yes, I think it's necessary. > Here's an example: > > void > sigalarmhandler(int sig) > { > longjmp(env, 1); > } > > int > somenslookup(...) > { > ... > alarm(5); /* Wait a maximum of 5 seconds. */ > if (setjmp(env) == 0) { > nsdispatch(...); > return (0); > } > return (-1); > } > > Now perhaps this isn't the best example; imagine using > something that used malloc()/free() or any one of the other > locked libc functions. There is also the use of application > level-locks which should work similarly, but by using libc > example I avoid any argument about "the application shouldn't > be doing that" :-) If I understand correctly what you are saying is if the alarm fires before somenslookup() returns successfully, the longjmp will make it return unsuccessfully, and if it happened to be put on a queue in nsdispatch() it will return to its caller still on the queue (which we clearly don't want). How is this any different than holding some other resource? For example, if it had managed to aquire the lock before the longjmp from the signal handler? See below for what I mean. > It's also possible that the thread calls the same set > of libc functions again, and if it isn't removed from > the internal mutex queue, then you'd get the exact > error message Marcel was seeing (already on mutexq). I'm glad you brought this last point up because that has been on my mind as well. Let's say an application is in one of the locked libc functions, receives a signal and calls that same libc function from it's signal handler. Furthermore, let's say that the thread had just aquired a lock in the libc funtion before handling the signal. When this thread called the same libc function from the signal handler and tried to aquire the same lock again, would it not deadlock against itself? So, the problem is not that the mutex/cond queues are special. It's that locking from within libc in general is special, right? I guess part of what has me confused is why the queues are being treated so specially. I think the problem is one of general re-entrancy for library functions designated async or thread safe. If so, then once I have a proper handle on the issues I can start addressing them in libthr. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 16:10:27 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A072737B401 for ; Fri, 27 Jun 2003 16:10:27 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF86744005 for ; Fri, 27 Jun 2003 16:10:26 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5RNAPXh018491; Fri, 27 Jun 2003 19:10:25 -0400 (EDT) Date: Fri, 27 Jun 2003 19:10:25 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 23:10:28 -0000 On Fri, 27 Jun 2003, Mike Makonnen wrote: > On Fri, 27 Jun 2003 07:14:43 -0400 (EDT) > Daniel Eischen wrote: > > > > > To answer your first question, yes, I think it's necessary. > > Here's an example: > > > > void > > sigalarmhandler(int sig) > > { > > longjmp(env, 1); > > } > > > > int > > somenslookup(...) > > { > > ... > > alarm(5); /* Wait a maximum of 5 seconds. */ > > if (setjmp(env) == 0) { > > nsdispatch(...); > > return (0); > > } > > return (-1); > > } > > > > Now perhaps this isn't the best example; imagine using > > something that used malloc()/free() or any one of the other > > locked libc functions. There is also the use of application > > level-locks which should work similarly, but by using libc > > example I avoid any argument about "the application shouldn't > > be doing that" :-) > > If I understand correctly what you are saying is if the alarm fires before > somenslookup() returns successfully, the longjmp will make it return > unsuccessfully, and if it happened to be put on a queue in nsdispatch() it will > return to its caller still on the queue (which we clearly don't want). Right. > How is this any different than holding some other resource? For example, if > it had managed to aquire the lock before the longjmp from the signal handler? > See below for what I mean. Libc mutexes and CVs use the single underscore version so our threads library can tell the difference between implementation locks and application locks. We should be deferring signals while _holding_ one of these locks. Mutexes in libc should be very short term, so deferring signals while being held should be OK. But for CV's, you could be on the CV queue for some time, and you shouldn't be holding up signal delivery because of that. My rule of thumb is to treat all locks the same and don't keep threads on waiting queues of any sort while running signal handlers. But once a lock is held, that's a bit different because the application could longjmp() out of the locked region and never release the lock. We should probably defer signal delivery while implementation mutexes, spinlocks, and low-level locks are held. > > It's also possible that the thread calls the same set > > of libc functions again, and if it isn't removed from > > the internal mutex queue, then you'd get the exact > > error message Marcel was seeing (already on mutexq). > > I'm glad you brought this last point up because that has been on my mind as > well. Let's say an application is in one of the locked libc functions, receives > a signal and calls that same libc function from it's signal handler. > Furthermore, let's say that the thread had just aquired a lock in the libc > funtion before handling the signal. When this thread called the same libc > function from the signal handler and tried to aquire the same lock again, would > it not deadlock against itself? Yes, I think it would. > So, the problem is not that the mutex/cond queues are special. It's that locking > from within libc in general is special, right? For the most part, yes. I don't differentiate between being on an application mutex/CV's queue or on an implementation mutex/CV's queue, though. I always treat them the same and remove the thread from the synchronization object's waiting queue before delivering the signal, then reinsert the thread again if the signal handler returns normally. If you don't do that, then your queues become corrupted. > I guess part of what has me confused is why the queues are being treated so > specially. I think the problem is one of general re-entrancy for library > functions designated async or thread safe. If so, then once I have a proper > handle on the issues I can start addressing them in libthr. I do recall that when I was working on libc_r, these issues always came up, and the simplest way to fix them (or work around them) was to always make sure the queues were consistent and always remove threads from these queues before calling signal handlers. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 16:42:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22BDD37B401; Fri, 27 Jun 2003 16:42:25 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A1B643F93; Fri, 27 Jun 2003 16:42:24 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([141.156.32.244]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627234223.SVVN12592.out001.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 18:42:23 -0500 Date: Fri, 27 Jun 2003 19:42:22 -0400 From: Mike Makonnen To: deischen@freebsd.org In-Reply-To: References: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [141.156.32.244] at Fri, 27 Jun 2003 18:42:23 -0500 Message-Id: <20030627234223.SVVN12592.out001.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 23:42:25 -0000 On Fri, 27 Jun 2003 19:10:25 -0400 (EDT) Daniel Eischen wrote: > > > How is this any different than holding some other resource? For example, if > > it had managed to aquire the lock before the longjmp from the signal > > handler? See below for what I mean. > > Libc mutexes and CVs use the single underscore version > so our threads library can tell the difference between > implementation locks and application locks. We should > be deferring signals while _holding_ one of these locks. > Mutexes in libc should be very short term, so deferring > signals while being held should be OK. But for CV's, > you could be on the CV queue for some time, and you > shouldn't be holding up signal delivery because of > that. > > My rule of thumb is to treat all locks the same and > don't keep threads on waiting queues of any sort while > running signal handlers. But once a lock is held, > that's a bit different because the application could > longjmp() out of the locked region and never release > the lock. We should probably defer signal delivery > while implementation mutexes, spinlocks, and low-level > locks are held. > Ok, thanks for all the input. I think I know what needs to be done now. 1. I'll change the stubs in libthr so that locking operations from within libc defer signals. 2. Fix the sigwrapper in libthr and introduce wrapper functions around signal(3) and sigaction(2) so that calls to signal handlers can be properly indirected through the sigwrapper function. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 23:35:06 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 179DE37B401 for ; Fri, 27 Jun 2003 23:35:06 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AAEC43F75 for ; Fri, 27 Jun 2003 23:35:05 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5S6Z4DZ038030 for ; Fri, 27 Jun 2003 23:35:04 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5S6Z4DG037457 for ; Fri, 27 Jun 2003 23:35:04 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5S6Z3VH037456 for threads@FreeBSD.org; Fri, 27 Jun 2003 23:35:03 -0700 (PDT) Date: Fri, 27 Jun 2003 23:35:03 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org Message-ID: <20030628063503.GA37411@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 06:35:06 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, I've started runtime testing and ran into ILP32/LP64 bugs. Attached a patch that solve the first problems without affecting i386. The patch is intended to illustrate the problem more than it suggest a solution. I'm more than happy to test alternative solutions. Note that the use of uint32_t instead of unsigned int is mostly to mirror the use of fuword32/suword32... FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kse.diff" Index: kern/kern_thread.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v retrieving revision 1.145 diff -u -r1.145 kern_thread.c --- kern/kern_thread.c 20 Jun 2003 09:12:12 -0000 1.145 +++ kern/kern_thread.c 28 Jun 2003 05:12:23 -0000 @@ -958,8 +958,8 @@ /* Exports clock ticks in kernel mode */ addr = (caddr_t)(&td->td_mailbox->tm_sticks); - temp = fuword(addr) + td->td_usticks; - if (suword(addr, temp)) { + temp = fuword32(addr) + td->td_usticks; + if (suword32(addr, temp)) { error = EFAULT; goto bad; } @@ -1096,7 +1096,7 @@ addr = (caddr_t)&tmbx->tm_sticks; } if (uticks) { - if (suword(addr, uticks+fuword(addr))) { + if (suword32(addr, uticks+fuword32(addr))) { PROC_LOCK(p); psignal(p, SIGSEGV); PROC_UNLOCK(p); @@ -1518,7 +1518,7 @@ KASSERT(ku, ("%s: no upcall owned", __func__)); KASSERT((ku->ku_owner == td), ("%s: wrong owner", __func__)); KASSERT(!TD_CAN_UNBIND(td), ("%s: can unbind", __func__)); - ku->ku_mflags = fuword((void *)&ku->ku_mailbox->km_flags); + ku->ku_mflags = fuword32((void *)&ku->ku_mailbox->km_flags); tmbx = (void *)fuword((void *)&ku->ku_mailbox->km_curthread); if ((tmbx == NULL) || (tmbx == (void *)-1)) { td->td_mailbox = NULL; Index: sys/kse.h =================================================================== RCS file: /home/ncvs/src/sys/sys/kse.h,v retrieving revision 1.15 diff -u -r1.15 kse.h --- sys/kse.h 15 Jun 2003 12:51:26 -0000 1.15 +++ sys/kse.h 28 Jun 2003 05:12:37 -0000 @@ -57,9 +57,9 @@ unsigned int tm_flags; /* Thread flags */ struct kse_thr_mailbox *tm_next; /* Next thread in list */ void *tm_udata; /* For use by the UTS */ - unsigned int tm_uticks; - unsigned int tm_sticks; - int tm_spare[8]; + uint32_t tm_uticks; + uint32_t tm_sticks; + uint32_t tm_spare[8]; }; /* @@ -73,7 +73,7 @@ struct kse_thr_mailbox *km_curthread; /* Currently running thread */ struct kse_thr_mailbox *km_completed; /* Threads back from kernel */ sigset_t km_sigscaught; /* Caught signals */ - unsigned int km_flags; /* KSE flags */ + uint32_t km_flags; /* KSE flags */ kse_func_t *km_func; /* UTS function */ stack_t km_stack; /* UTS context */ void *km_udata; /* For use by the UTS */ --tKW2IUtsqtDRztdT-- From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 23:52:05 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7499237B404; Fri, 27 Jun 2003 23:52:05 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B2944013; Fri, 27 Jun 2003 23:52:04 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5S6q2iP011076; Fri, 27 Jun 2003 23:52:02 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5S6q0r0011075; Fri, 27 Jun 2003 23:52:00 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 27 Jun 2003 23:52:00 -0700 From: David Schultz To: Mike Makonnen Message-ID: <20030628065200.GA10309@HAL9000.homeunix.com> Mail-Followup-To: Mike Makonnen , deischen@freebsd.org, freebsd-threads@freebsd.org, marcel@xcllnt.net References: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> cc: deischen@FreeBSD.ORG cc: marcel@xcllnt.net cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 06:52:05 -0000 On Fri, Jun 27, 2003, Mike Makonnen wrote: > I'm glad you brought this last point up because that has been on my mind as > well. Let's say an application is in one of the locked libc functions, receives > a signal and calls that same libc function from it's signal handler. > Furthermore, let's say that the thread had just aquired a lock in the libc > funtion before handling the signal. When this thread called the same libc > function from the signal handler and tried to aquire the same lock again, would > it not deadlock against itself? This is interesting in that it mirrors a general issue that comes up in the kernel. Specifically, the kernel needs to deal with the problem where an interrupt handler tries to acquire a kernel lock that is held by the thread it interrupted. Traditionally, Unix has dealt with the problem using a technique analogous to what Dan suggested, namely, by blocking the relevant interrupts while accessing data structures that interrupt handlers might need to use. That approach doesn't work on a multiprocessor, though, so the usual fix is to simply accept the fact that an interrupt handler may want a lock that's already held, and allow it to block. The userland analogue of that, i.e. giving a thread context to each signal handler, probably won't fly. ;-) Andersen had to deal with the issue of a thread (possibly the UTS) being preempted while holding a lock in his Scheduler Activations work. He solved the problem by having the UTS check at the time of preemption whether the preempted thread was running in a critical section, and if so, defer the preemption. However, instead of explicitly enabling and disabling preemption all the time, he used the trick of checking at preemption time whether the PC fell within certain ranges. In practice, that's probably too hard, but it works well in special cases, such as preventing the UTS from deadlocking against itself. BTW, as you probably know already, POSIX only requires a handful of functions to be async-signal safe, and even malloc/free aren't among them... From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 03:01:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4006537B401 for ; Sat, 28 Jun 2003 03:01:04 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id C630443FDD for ; Sat, 28 Jun 2003 03:01:02 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (gprs-prointernet-3e47d5f8.mobile.inet.fi [62.71.213.248]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h5SA0msL018862 for ; Sat, 28 Jun 2003 13:00:55 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <001501c33d5c$2ba7ab00$f8d5473e@PETEX31> From: "Petri Helenius" To: Date: Sat, 28 Jun 2003 11:29:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: rtprio and kse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 10:01:04 -0000 How does kse and rtprio interact? If a thread calls to set realtime priority does that set the priority for all threads, just the threads that happen to be scheduled on that kse or just the thread that made the call? Pete From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 07:06:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 360B037B401 for ; Sat, 28 Jun 2003 07:06:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F6A4402B for ; Sat, 28 Jun 2003 07:06:03 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5SE62Xh024929; Sat, 28 Jun 2003 10:06:02 -0400 (EDT) Date: Sat, 28 Jun 2003 10:06:02 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030628063503.GA37411@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 14:06:04 -0000 On Fri, 27 Jun 2003, Marcel Moolenaar wrote: > Ok, > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > a patch that solve the first problems without affecting i386. The > patch is intended to illustrate the problem more than it suggest a > solution. I'm more than happy to test alternative solutions. > Note that the use of uint32_t instead of unsigned int is mostly > to mirror the use of fuword32/suword32... I don't have any problem with the patch. Is there another solution you'd rather see, perhaps using 64bit values? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 07:15:00 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BD1837B401; Sat, 28 Jun 2003 07:15:00 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92EE84400D; Sat, 28 Jun 2003 07:14:59 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5SEEvXh026317; Sat, 28 Jun 2003 10:14:58 -0400 (EDT) Date: Sat, 28 Jun 2003 10:14:57 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Schultz In-Reply-To: <20030628065200.GA10309@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 14:15:00 -0000 On Fri, 27 Jun 2003, David Schultz wrote: > On Fri, Jun 27, 2003, Mike Makonnen wrote: > > I'm glad you brought this last point up because that has been on my mind as > > well. Let's say an application is in one of the locked libc functions, receives > > a signal and calls that same libc function from it's signal handler. > > Furthermore, let's say that the thread had just aquired a lock in the libc > > funtion before handling the signal. When this thread called the same libc > > function from the signal handler and tried to aquire the same lock again, would > > it not deadlock against itself? > > This is interesting in that it mirrors a general issue that comes > up in the kernel. Specifically, the kernel needs to deal with the > problem where an interrupt handler tries to acquire a kernel lock > that is held by the thread it interrupted. Traditionally, Unix > has dealt with the problem using a technique analogous to what Dan > suggested, namely, by blocking the relevant interrupts while > accessing data structures that interrupt handlers might need to > use. That approach doesn't work on a multiprocessor, though, so > the usual fix is to simply accept the fact that an interrupt > handler may want a lock that's already held, and allow it to > block. The userland analogue of that, i.e. giving a thread > context to each signal handler, probably won't fly. ;-) > > Andersen had to deal with the issue of a thread (possibly the UTS) > being preempted while holding a lock in his Scheduler Activations > work. He solved the problem by having the UTS check at the time > of preemption whether the preempted thread was running in a > critical section, and if so, defer the preemption. However, > instead of explicitly enabling and disabling preemption all the > time, he used the trick of checking at preemption time whether the > PC fell within certain ranges. In practice, that's probably too > hard, but it works well in special cases, such as preventing the > UTS from deadlocking against itself. Andersen also talked about just setting a flag when a thread was in a critical region. Libpthread uses a similar method; right now there are a couple of things that denote a thread being in a critical region. Signals are not blocked while threads are in critical region; they are deferred (latched and handled once the critical region is exited). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 08:30:34 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DFCA37B401; Sat, 28 Jun 2003 08:30:34 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8D334402B; Sat, 28 Jun 2003 08:30:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SFUWDZ043497; Sat, 28 Jun 2003 08:30:32 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SFUWsi000669; Sat, 28 Jun 2003 08:30:32 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5SFUWu0000668; Sat, 28 Jun 2003 08:30:32 -0700 (PDT) Date: Sat, 28 Jun 2003 08:30:32 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030628153032.GA577@dhcp01.pn.xcllnt.net> References: <20030628063503.GA37411@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 15:30:34 -0000 On Sat, Jun 28, 2003 at 10:06:02AM -0400, Daniel Eischen wrote: > > > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > > a patch that solve the first problems without affecting i386. The > > patch is intended to illustrate the problem more than it suggest a > > solution. I'm more than happy to test alternative solutions. > > Note that the use of uint32_t instead of unsigned int is mostly > > to mirror the use of fuword32/suword32... > > I don't have any problem with the patch. Is there another > solution you'd rather see, perhaps using 64bit values? I was thinking about using long. fuword/suword is defined in terms of long, so technically it's a bug to have them operate on int. But using long will yield 64-bit fields on 64-bit platforms, and it may just be a waste of space. Although internal alignment and padding may already take up as much space (tm_flags, km_version, km_flags are examples of this). I'm divided on the issue. I prefer using long for it being the best native type, but don't like the immediate consequence of it being too variable for use in interface types (take for example the 64-bit long on i386 that bde is playing with). With the patch I favored the fixed width property on uint32_t. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 09:20:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEBC637B401 for ; Sat, 28 Jun 2003 09:20:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF5F44400F for ; Sat, 28 Jun 2003 09:20:03 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5SGK3Xh012510; Sat, 28 Jun 2003 12:20:03 -0400 (EDT) Date: Sat, 28 Jun 2003 12:20:03 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030628153032.GA577@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 16:20:05 -0000 On Sat, 28 Jun 2003, Marcel Moolenaar wrote: > On Sat, Jun 28, 2003 at 10:06:02AM -0400, Daniel Eischen wrote: > > > > > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > > > a patch that solve the first problems without affecting i386. The > > > patch is intended to illustrate the problem more than it suggest a > > > solution. I'm more than happy to test alternative solutions. > > > Note that the use of uint32_t instead of unsigned int is mostly > > > to mirror the use of fuword32/suword32... > > > > I don't have any problem with the patch. Is there another > > solution you'd rather see, perhaps using 64bit values? > > I was thinking about using long. fuword/suword is defined in terms > of long, so technically it's a bug to have them operate on int. But > using long will yield 64-bit fields on 64-bit platforms, and it may > just be a waste of space. Although internal alignment and padding > may already take up as much space (tm_flags, km_version, km_flags > are examples of this). The mailboxes are not that big (with the exception of the thread mailbox due to ucontext), so a few extra bytes isn't going to hurt userland. Perhaps the copyin/copyout's in the kernel is what you're worried about? > I'm divided on the issue. I prefer using long for it being the best > native type, but don't like the immediate consequence of it being > too variable for use in interface types (take for example the 64-bit > long on i386 that bde is playing with). With the patch I favored > the fixed width property on uint32_t. You can use uint32_t for now as a quick fix. Perhaps we should restructure the mailboxen a bit as a longer term fix. David just added siginfo to the thread mailbox, so that's another MD structure. struct kse_thr_mailbox { /* u_long tm_version; */ /* ??? */ struct kse_thr_mailbox *tm_next; void *tm_udata; uint32_t tm_flags; uint32_t tm_uticks; uint32_t tm_sticks; uint32_t tm_spare[9]; siginfo_t tm_syncsig; ucontext_t tm_context; } This allows tm_context to change without affecting offsets to the other fields. The KSE mailbox has a version in it which can also identify what version of the thread mailbox, but it might make sense to stick a version field in the thread mailbox to make things easier. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 10:54:37 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 603CA37B401; Sat, 28 Jun 2003 10:54:37 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 719434402B; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SHsaDZ044066; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SHsasi001125; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5SHsa3p001124; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) Date: Sat, 28 Jun 2003 10:54:36 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030628175436.GA1071@dhcp01.pn.xcllnt.net> References: <20030628153032.GA577@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 17:54:37 -0000 On Sat, Jun 28, 2003 at 12:20:03PM -0400, Daniel Eischen wrote: > > > > I was thinking about using long. fuword/suword is defined in terms > > of long, so technically it's a bug to have them operate on int. But > > using long will yield 64-bit fields on 64-bit platforms, and it may > > just be a waste of space. Although internal alignment and padding > > may already take up as much space (tm_flags, km_version, km_flags > > are examples of this). > > The mailboxes are not that big (with the exception of the > thread mailbox due to ucontext), so a few extra bytes isn't > going to hurt userland. Perhaps the copyin/copyout's in > the kernel is what you're worried about? Not really. It's just that I like to be able to defend the size expansion when an alternative exists that does not increase the size. > > I'm divided on the issue. I prefer using long for it being the best > > native type, but don't like the immediate consequence of it being > > too variable for use in interface types (take for example the 64-bit > > long on i386 that bde is playing with). With the patch I favored > > the fixed width property on uint32_t. > > You can use uint32_t for now as a quick fix. Perhaps > we should restructure the mailboxen a bit as a longer > term fix. David just added siginfo to the thread > mailbox, so that's another MD structure. Sounds good. Note that on ia64 ucontext_t has 16-byte alignment. Having the fields reordered definitely helps the overall density. BTW: putting tm_context at the end is a good idea. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 12:28:18 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E8AC37B401; Sat, 28 Jun 2003 12:28:18 -0700 (PDT) Received: from InterJet.elischer.org (12-233-125-100.client.attbi.com [12.233.125.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2ED443FF5; Sat, 28 Jun 2003 12:28:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA32172; Sat, 28 Jun 2003 12:28:10 -0700 (PDT) Date: Sat, 28 Jun 2003 12:28:09 -0700 (PDT) From: Julian Elischer To: Marcel Moolenaar In-Reply-To: <20030628153032.GA577@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 19:28:18 -0000 we also need a fuptr and suptr for pointers. On Sat, 28 Jun 2003, Marcel Moolenaar wrote: > On Sat, Jun 28, 2003 at 10:06:02AM -0400, Daniel Eischen wrote: > > > > > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > > > a patch that solve the first problems without affecting i386. The > > > patch is intended to illustrate the problem more than it suggest a > > > solution. I'm more than happy to test alternative solutions. > > > Note that the use of uint32_t instead of unsigned int is mostly > > > to mirror the use of fuword32/suword32... > > > > I don't have any problem with the patch. Is there another > > solution you'd rather see, perhaps using 64bit values? > > I was thinking about using long. fuword/suword is defined in terms > of long, so technically it's a bug to have them operate on int. But > using long will yield 64-bit fields on 64-bit platforms, and it may > just be a waste of space. Although internal alignment and padding > may already take up as much space (tm_flags, km_version, km_flags > are examples of this). > > I'm divided on the issue. I prefer using long for it being the best > native type, but don't like the immediate consequence of it being > too variable for use in interface types (take for example the 64-bit > long on i386 that bde is playing with). With the patch I favored > the fixed width property on uint32_t. > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > _______________________________________________ > 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 Jun 28 12:37:52 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5080D37B401 for ; Sat, 28 Jun 2003 12:37:52 -0700 (PDT) Received: from thuis.piwebs.com (217-19-20-186.dsl.cambrium.nl [217.19.20.186]) by mx1.FreeBSD.org (Postfix) with SMTP id A98E844014 for ; Sat, 28 Jun 2003 12:37:49 -0700 (PDT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 13243 invoked by uid 85); 28 Jun 2003 19:37:52 -0000 Received: from avleeuwen@piwebs.com by thuis.piwebs.com by uid 82 with qmail-scanner-1.15 (uvscan: v4.1.60/v4210. spamassassin: 2.x. Clear:SA:0(-2.6/5.0):. Processed in 11.098165 secs); 28 Jun 2003 19:37:52 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 Received: from unknown (HELO 192.168.0.109) (192.168.0.109) by 0 with SMTP; 28 Jun 2003 19:37:41 -0000 From: Arjan van Leeuwen To: threads@freebsd.org Date: Sat, 28 Jun 2003 21:37:36 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306282137.36740.avleeuwen@piwebs.com> cc: kde@freebsd.org Subject: libkse & konsole X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 19:37:52 -0000 Hi, With the newest libkse library (mapped via libmap.conf) I can not start KDE's terminal emulator Konsole anymore. Until recently, it was possible to start Konsole with libkse, although it would crash about 50% of the time (it always worked fine when it was started though). Now, it crashes 100% of the time. I'm not able to use it anymore. Is there any information I can provide that might help to solve this problem? Best regards, Arjan From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 12:46:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDF7237B401; Sat, 28 Jun 2003 12:46:26 -0700 (PDT) Received: from InterJet.elischer.org (12-233-125-100.client.attbi.com [12.233.125.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4067243FBF; Sat, 28 Jun 2003 12:46:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA32317; Sat, 28 Jun 2003 12:46:14 -0700 (PDT) Date: Sat, 28 Jun 2003 12:46:13 -0700 (PDT) From: Julian Elischer To: Arjan van Leeuwen In-Reply-To: <200306282137.36740.avleeuwen@piwebs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: kde@freebsd.org Subject: Re: libkse & konsole X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 19:46:27 -0000 you MAY have gotten it in tehmiddle of the update... also, have you recompiled both the kernel and the library? On Sat, 28 Jun 2003, Arjan van Leeuwen wrote: > Hi, > > With the newest libkse library (mapped via libmap.conf) I can not start KDE's > terminal emulator Konsole anymore. > > Until recently, it was possible to start Konsole with libkse, although it > would crash about 50% of the time (it always worked fine when it was started > though). > > Now, it crashes 100% of the time. I'm not able to use it anymore. Is there any > information I can provide that might help to solve this problem? > > Best regards, > > Arjan > > _______________________________________________ > 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 Jun 28 13:00:31 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABAEB37B401 for ; Sat, 28 Jun 2003 13:00:31 -0700 (PDT) Received: from thuis.piwebs.com (217-19-20-186.dsl.cambrium.nl [217.19.20.186]) by mx1.FreeBSD.org (Postfix) with SMTP id C718843FB1 for ; Sat, 28 Jun 2003 13:00:29 -0700 (PDT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 13436 invoked by uid 85); 28 Jun 2003 20:00:33 -0000 Received: from avleeuwen@piwebs.com by thuis.piwebs.com by uid 82 with qmail-scanner-1.15 (uvscan: v4.1.60/v4210. spamassassin: 2.x. Clear:SA:0(-4.6/5.0):. Processed in 11.032353 secs); 28 Jun 2003 20:00:33 -0000 X-Spam-Status: No, hits=-4.6 required=5.0 Received: from unknown (HELO 192.168.0.109) (192.168.0.109) by 0 with SMTP; 28 Jun 2003 20:00:21 -0000 From: Arjan van Leeuwen To: Julian Elischer Date: Sat, 28 Jun 2003 22:00:16 +0200 User-Agent: KMail/1.5.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306282200.17022.avleeuwen@piwebs.com> cc: threads@freebsd.org cc: kde@freebsd.org Subject: Re: libkse & konsole & unkillable process (was: libkse & konsole) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 20:00:32 -0000 Hey Julian, On Saturday 28 June 2003 21:46, Julian Elischer wrote: > you MAY have gotten it in tehmiddle of the update... I doubt it... I've just re-cvsupped, and nothing has changed in kse. > also, have you recompiled both the kernel and the library? Yup. Also, when I sent the previous email, I discovered that kmail didn't respond anymore, and, worse, it couldn't be killed anymore. This also looks like regression to me. After I've sent this mail, I'll see if it's reproducable :). Arjan > > On Sat, 28 Jun 2003, Arjan van Leeuwen wrote: > > Hi, > > > > With the newest libkse library (mapped via libmap.conf) I can not start > > KDE's terminal emulator Konsole anymore. > > > > Until recently, it was possible to start Konsole with libkse, although it > > would crash about 50% of the time (it always worked fine when it was > > started though). > > > > Now, it crashes 100% of the time. I'm not able to use it anymore. Is > > there any information I can provide that might help to solve this > > problem? > > > > Best regards, > > > > Arjan > > > > _______________________________________________ > > 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 Jun 28 16:57:41 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36F6037B401; Sat, 28 Jun 2003 16:57:41 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B691643FB1; Sat, 28 Jun 2003 16:57:38 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h5SNvaUp048739; Sat, 28 Jun 2003 16:57:37 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <000d01c33dd1$80363040$0701a8c0@tiger> From: "David Xu" To: "Arjan van Leeuwen" , References: <200306282137.36740.avleeuwen@piwebs.com> Date: Sun, 29 Jun 2003 08:00:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: kde@freebsd.org Subject: Re: libkse & konsole X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 23:57:41 -0000 Anyone if has interest to dig it out, here is the kconsole problem code: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/konsole/konsole/TEPty.cp= p?rev=3D1.69&content-type=3Dtext/x-cvsweb-markup Look into memember function makePty(bool _addutmp) of class TEPty, there are some abort() calls, I think one of them is triggered. Unfortunatly, unlike other KDE codes, it does not print debug message in X11 startup text console. BTW, kconsole is working as same as before I commited the new signal = code. On my machine, 50% crashes, 50% works. David Xu ----- Original Message -----=20 From: "Arjan van Leeuwen" To: Cc: Sent: Sunday, June 29, 2003 3:37 AM Subject: libkse & konsole > Hi, >=20 > With the newest libkse library (mapped via libmap.conf) I can not = start KDE's=20 > terminal emulator Konsole anymore.=20 >=20 > Until recently, it was possible to start Konsole with libkse, although = it=20 > would crash about 50% of the time (it always worked fine when it was = started=20 > though).=20 >=20 > Now, it crashes 100% of the time. I'm not able to use it anymore. Is = there any=20 > information I can provide that might help to solve this problem? >=20 > Best regards, >=20 > Arjan >=20 > _______________________________________________ > 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" >