Date: Sat, 12 Jun 2004 07:22:23 +0800 From: David Xu <davidxu@freebsd.org> To: Sean McNeil <sean@mcneil.com> Cc: Daniel Eischen <eischen@vigrid.com> Subject: Re: signal handler priority issue Message-ID: <40CA3EAF.70508@freebsd.org> In-Reply-To: <1086993632.45971.2.camel@server.mcneil.com> References: <Pine.GSO.4.10.10406110432370.12394-100000@pcnet5.pcnet.com> <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> <1086977738.70017.9.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org> <1086993632.45971.2.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean McNeil wrote: >On Fri, 2004-06-11 at 15:32, David Xu wrote: > > >>Sean McNeil wrote: >> >> >> >>>On Fri, 2004-06-11 at 07:40, David Xu wrote: >>> >>> >>> >>> >>>>Sean McNeil wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Sorry for top-posting, but it may be easier to read this way.... >>>>> >>>>>The program below has an optimization bug in that done isn't declare >>>>>volatile. With that fixed, it works just fine. I've been attempting to >>>>>get boehm-gc working and it seems OK with libc_r, but fails with >>>>>libpthread. It is essentially doing what the program below does, but >>>>>for some reason it gets stuck. Has anyone else been experimenting with >>>>>boehm-gc? >>>>> >>>>>Also, it would really help if I had a debugger that worked with kse >>>>>threads. How is that going? Tracking down pthread issues right now has >>>>>been difficult with the current debugger. Can anyone throw some patches >>>>>my way that may help? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Please try the patch: >>>>http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff >>>> >>>>the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, >>>>I believe I caught a bug in the sigsuspend(), thread >>>>should scan pending signals first, only when there is >>>>no pending signal in wait set, the thread can sleep. >>>> >>>> >>>> >>>> >>>Also, the mask provided by the sigsuspend call should govern what >>>handlers get called. So the sigmask should be left in place until after >>>the _thr_sig_check_pending(curthread) call. >>> >>>Thanks for catching this :) >>> >>>Sean >>> >>> >>> >>> >>> >>> >>> >>> >>No the patch is still not correct, before >>_thr_sched_switch_unlocked(curthread) returns, signal will be delivered, >>so there needs a flag to tell signal dispatching code to use old signal mask >>when delivering signal to signal handler. I am working on it, >>thanks for your patch. >> >> > >What old signal mask? It should be the signals that sigsuspend allows >that get handled within sigsuspend. Make sure the following can still >happen: > >signal is masked. >sigsuspend is called with signal unmasked. >signal comes in or is pending already. >signal handler is called. >sigsuspend returns. > >Sean > > > > > when signal handler is called in sigsuspend(), thread signal masks is set to the signal set sigsuspend passes and ored with the signal current is being handled. uc_sigmask in ucontext is set to the signal masks before sigsuspend is called, when the signal handler is returned, uc_sigmask should be copied to thread's signal mask, then sigsuspend returns. your patch does not set uc_sigmasks correctly. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40CA3EAF.70508>