From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 20:17:22 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 824B737B401; Sun, 6 Apr 2003 20:17:22 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB6BC43F93; Sun, 6 Apr 2003 20:17:21 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <20030407031720002004nv4ke>; Mon, 7 Apr 2003 03:17:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA57001; Sun, 6 Apr 2003 20:17:19 -0700 (PDT) Date: Sun, 6 Apr 2003 20:17:17 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <003501c2fca3$3e20c900$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 03:17:22 -0000 On Mon, 7 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Sunday, April 06, 2003 8:39 PM > Subject: Re: PS_BLOCKED > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > ----- Original Message ----- > > > From: "Daniel Eischen" > > > To: "DavidXu" > > > Cc: > > > Sent: Sunday, April 06, 2003 2:40 PM > > > Subject: Re: PS_BLOCKED > > > ... > > > > I'll do some more debugging today and see if it is in the > > UTS or the kernel. > > > > Note that Jeff's change to signal code in kernel also broke > our kse_release code, because the upcall thread is waiting for > signal in kse_release too, but now it is possible the upcall > thread won't receive any signal, signal is delivered to a > non-upcall thread and lost. > > > > > One question. What happens when kse_release(tsp) is > > > > called when k_mbx.km_curthread == NULL? Does it > > > > just return after the timeout, or is there a new > > > > upcall? > > > > > > A new upcall will be scheduled, does not return. > > > > Is there a way that we could get it to just return? I would > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > KSE/KSEG) work without a separate scheduler stack. We > > should be able to do everything from the thread's stack. > > I'd be willing to add a flag or something to the KSE > > mailbox to get this behaviour. > > > > It can be done by add a flags to kse_mailbox.km_flags to > tell kernel to not schedule an upcall. If you have this behaviour, please make it an option. Possibly One way to do this would be to call kse_create, with the 'new-ksegrp' flag set but the mailbox pointer set to NULL. However why do you want to use kse_release for this. If you have only one thread in the KSEGRP then I'd call this "usleep()". I think kse_release should be left alone. It should never return. > > > > > And if kse_A->k_mbx.km_curthread == NULL > > > > and it is in a kse_release(tsp), can another kse > > > > interrupt it (before the timeout) with kse_wakeup()? > > > > > > > Yes, you can use kse_wakeup to interrupt it, pass the > > > kse mailbox address to the syscall. > > > > Cool, that's what I thought. > > > > I forgot to mention it, but I think I found a kernel bug also. > > Sometimes when the kernel exports a context to the UTS the > > %gs register isn't set; it doesn't seem to be saved in some > > instances. I think it might only be when a kernel thread > > is swapped out (without blocking). Does %gs always get saved, > > even if the thread is interrupted by an interrupt? > > > > Yes, I will fix it and give you a patch. > > > > > -- > > > > Dan Eischen > > > > > > > > > > > > Let's Go Orange! > > > > > > Would there be a new patch against code in the src tree > > > I can download ? > > > > Done. I'll try to do some more debugging and update it again > > later today. > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > Got it! > > > -- > > Dan Eischen > > _______________________________________________ > 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" >