Garrett Wollman wrote:
>
> <<On Mon, 06 Sep 1999 19:34:06 +0200, Marcel Moolenaar <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
