Date: Fri, 11 Jun 2004 15:40:32 -0700 From: Sean McNeil <sean@mcneil.com> To: David Xu <davidxu@freebsd.org> Cc: Daniel Eischen <eischen@vigrid.com> Subject: Re: signal handler priority issue Message-ID: <1086993632.45971.2.camel@server.mcneil.com> In-Reply-To: <40CA330F.5090103@freebsd.org> 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> <1086977738.70017.9.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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. Seanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086993632.45971.2.camel>