Date: Mon, 06 Sep 1999 19:34:06 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: current@FreeBSD.ORG Subject: Re: (P)review: sigset_t for more than 32 signals Message-ID: <37D3FB0E.94662026@scc.nl> References: <37D38367.C297FD64@scc.nl> <199909061607.MAA03384@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote: > > <<On Mon, 06 Sep 1999 11:03:35 +0200, Marcel Moolenaar <marcel@scc.nl> said: > > > kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff > > There appear to be some fairly gratuitous name changes in here. Elaborate, please. > Also, my own feeling is that it would be better to continue to use > integral types for signal sets inside the kernel. This makes the code > much easier to follow (at least for me), and underlines the necessity > of compatibility interfaces if the size is ever changed again. Having an integral sigset_t, if at all possible, has the disadvantage that existing expressions on the new datatype are probably valid syntactically speaking, but may not be semantically valid, which makes debugging rather painful. Having a struct ensures that the compiler will barf. I just doubled the number of signals in a sigset_t, because it was planned that way (compatibility with NetBSD and such). The latest working version has thus 128 bits in a sigset_t. (BTW: That was before you asked me if I could hold off). > As for the setjmp/longjmp problems I mentioned... I wonder if it might > not be preferable to make them system calls as well. There are some > hints in the siglongjmp source code to suggest that the restoration of > context needs to be atomic with respect to signal masking and > delivery. That would make it possible to introduce versioning in > JMP_BUF structs, which would in turn make it easier to deal with > backwards compatibility in the future. The setjump/longjump family of functions are userland function AFAICT. For that reason I would not choose to add syscalls. If atomicy is a real problem, then it may be preferable to have the kernel help out. Anyway, this issue is basicly independent of the sigset_t change. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37D3FB0E.94662026>