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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086993632.45971.2.camel>