From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 18:14:33 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 8A4DD37B401 for ; Sun, 6 Apr 2003 18:14:33 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CAB443FA3 for ; Sun, 6 Apr 2003 18:14:29 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HLDQP2PS; Mon, 7 Apr 2003 09:00:58 +0800 Message-ID: <003501c2fca3$3e20c900$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Mon, 7 Apr 2003 09:15:57 +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: 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 01:14:33 -0000 ----- Original Message -----=20 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: > >=20 > > ----- Original Message -----=20 > > From: "Daniel Eischen" > > To: "DavidXu" > > Cc: > > Sent: Sunday, April 06, 2003 2:40 PM > > Subject: Re: PS_BLOCKED > > ... > > > I've still got one bug I am trying to hunt down with > > > signals -- the sigwait test fails. Process (kill) signals > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > if it is a kernel bug or not, but I suspect it's > > > something I'm doing. > > >=20 > >=20 > > I don't know if Jeff's signal change in kernel affects your code, > > but signals lost problem is still not fixed, a thread exports its > > context and exits would lost signals dispatched to it, even the > > signals is not for the thread, but for process. >=20 > I'll do some more debugging today and see if it is in the > UTS or the kernel. >=20 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 =3D=3D NULL? Does it > > > just return after the timeout, or is there a new > > > upcall? > >=20 > > A new upcall will be scheduled, does not return. >=20 > 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. >=20 It can be done by add a flags to kse_mailbox.km_flags to tell kernel to not schedule an upcall. > > > And if kse_A->k_mbx.km_curthread =3D=3D NULL > > > and it is in a kse_release(tsp), can another kse > > > interrupt it (before the timeout) with kse_wakeup()? > > >=20 > > Yes, you can use kse_wakeup to interrupt it, pass the > > kse mailbox address to the syscall. >=20 > Cool, that's what I thought. >=20 > 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? >=20 Yes, I will fix it and give you a patch. > > > --=20 > > > Dan Eischen > > >=20 > > >=20 > > > Let's Go Orange! > >=20 > > Would there be a new patch against code in the src tree=20 > > I can download ? >=20 > Done. I'll try to do some more debugging and update it again > later today. >=20 > http://people.freebsd.org/~deischen/libpthread.diffs >=20 Got it! > --=20 > Dan Eischen