Date: Sun, 17 Aug 2003 09:12:55 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: deischen@freebsd.org Cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() Message-ID: <20030817161255.GA567@dhcp42.pn.xcllnt.net> In-Reply-To: <Pine.GSO.4.10.10308170850530.4870-100000@pcnet5.pcnet.com> References: <20030817004956.GA52247@dhcp42.pn.xcllnt.net> <Pine.GSO.4.10.10308170850530.4870-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 17, 2003 at 08:54:56AM -0400, Daniel Eischen wrote: > > > > > > One question. When you call (the syscall) setcontext() from > > > _ia64_break_setcontext(), do you ignore the signal mask (uc.uc_sigmask)? > > > > Good point. I don't think so. > > OK, this will cause signal handling problems. You can > use another flag, but that would dirty up MI setcontext(). > Perhaps a separate ia64-specific system call? I actually have been thinking about using a flag. One that simply indicates that the sigmask field is valid or not. The advantage of such flag is that it makes the general interaction with user land versions of getcontext() much more predictable and increases the overall applicability of the *context syscalls. For example: libthr uses getcontext(2) but is not interested in the sigmask. It simply uses the syscall as an initialization for new threads. The context is passed to thr_create where we only use the mcontext part to setup the registers. libkse tries to avoid the syscalls. The userland versions don't save or restore signal masks. There too we use contexts without actually being interested in sigmasks. Also in libkse we see that the contexts created in the kernel and given to userland are not contexts that contains sigmasks. We simply copyout the mcontext part of the ucontext. So, it appears that most of our uses of contexts are such that we don't need to save and/or restore sigmasks. I think an UCF_SIGMASK flag to indicate that the context has a valid sigmask is a logical or natural way to have setcontext(2) operate well with getcontext(2), which always defines contexts with sigmasks and userland versions of getcontext() or other more specific uses of contexts that may or may not have a need to save the sigmask. Reasoning differently: if we were to introduce a new syscall, then the syscall would in effect be a clone of setcontext(2) with the difference that we don't restore a part of the context. This is duplication to avoid variation. Also, with a new syscall we introduce the notion of having 2 seperate contexts. This not only begs for a getcontext() clone that does not save the sigmask, but also begs for a flag to differentiate between those 2 contexts. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030817161255.GA567>