Date: Sat, 27 Dec 2003 10:41:47 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Doug Rabson <dfr@nlsystems.com> Cc: arch@freebsd.org Subject: Re: sigaltstack with threads Message-ID: <Pine.GSO.4.10.10312271026130.6635-100000@pcnet5.pcnet.com> In-Reply-To: <1072537553.1143.19.camel@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Dec 2003, Doug Rabson wrote: > On Sat, 2003-12-27 at 14:56, Daniel Eischen wrote: > > > > In the '96 POSIX spec, using sigaltstack() in threaded applications > > was undefined. The new (SUSv3 200[123]?) POSIX spec allows this > > but says "Use of this function by library threads that are not bound > > to kernel-scheduled entities results in undefined behavior". I think > > that allows you to make it per-thread, but what behavior do we > > want when there are multiple threads in a KSE/KSEG? Should it be > > per KSE or KSEG? > > I think that if its supported at all in threaded programs, it must be > per-thread state otherwise you can't prevent two different threads > colliding on the same signal stack. The kernel doesn't know about userland threads. More than one userland thread can run in one kernel thread. And there will be more than one kernel thread (for a KSE process) when threads block in the kernel. So when sigaltstack() is called by a thread and that thread blocks in the kernel and there are other kernel threads created (so libkse's UTS can continue), what behavior do we want? Since libkse's UTS has it's own signal handler for threads not bound to a KSE/KSEG, it may have to get involved if we want to honor signal delivery with a sigaltstack() stack. POSIX does say this behavior is undefined, so we could just ignore it for this case. > I can't quite see how this maps to > KSE/KSEG since I only have the most hazy model of that stuff in my head > right now. > > Anyway, I've worked around things by not setting SA_ONSTACK for the > handlers that I want to run on the thread stack.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10312271026130.6635-100000>