Marcel Moolenaar wrote:
> 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.
Before getting too far here, can we consider some other standard interfaces?
#include <ucontext.h>
int getcontext(ucontext_t *ucp);
int setcontext(const ucontext_t *ucp);
void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html
setjmp,longjmp,sigreturn,etc can all be done with this interface and it can
be used for libc_r and future kernel-assisted threading.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
