Date: Mon, 06 Sep 1999 21:56:43 +0200
From: Marcel Moolenaar <marcel@scc.nl>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: current@FreeBSD.ORG, jb@FreeBSD.ORG
Subject: Re: Signal changes and {,sig}{set,long}jmp
Message-ID: <37D41C7B.E7D715AD@scc.nl>
References: <37D38367.C297FD64@scc.nl> <199909061607.MAA03384@khavrinen.lcs.mit.edu> <37D3FB0E.94662026@scc.nl> <199909061841.OAA03894@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote:
>
> <<On Mon, 06 Sep 1999 19:34:06 +0200, Marcel Moolenaar <marcel@scc.nl> said:
>
> > The setjump/longjump family of functions are userland function
> > AFAICT.
>
> POSIX doesn't make any such distinction. Remember that setjmp/longjmp
> *already* enter the kernel, in order to save/restore the signal mask,
> so there isn't any real performance penalty! (Programs which need a
> cheaper version already have to use _{set,long}jmp, which doesn't play
> with the signal mask.)
Hmm... setjmp/longjmp syscalls... _setjmp/_longjmp userland functions... If
struct jmp_buf is defined in <machine/someheader.h> (maybe even
<machine/signal.h>, then I can not find any disadvantages. If atomicy (sp?)
is solved by it, then there's definitely an advantage.
sigsetjmp and siglongjmp can be implemented in terms of setjmp/_setjmp and
longjmp/_longjmp respectively to avoid redundance.
> If we're already changing sizeof(jmp_buf)
> and sizeof(struct sigcontext), then at a minimum it makes sense to
> have them be the same shape (which as I mentioned could simplify the
> thread scheduler).
In that case, it pays off. I simply haven't paid any attention to it yet.
BTW: The problem was not caused by setjmp itself, but by sigblock. It was
using the new syscalls instead of the "old" (compatibility) ones. That is
solved. make world is now broken in another place :-)
--
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?37D41C7B.E7D715AD>