Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Sep 1999 18:33:48 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Marcel Moolenaar <marcel@scc.nl>
Cc:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, current@FreeBSD.ORG, jb@FreeBSD.ORG
Subject:   Re: Signal changes and {,sig}{set,long}jmp 
Message-ID:  <19990907103348.2801F1CA8@overcee.netplex.com.au>
In-Reply-To: Your message of "Mon, 06 Sep 1999 21:56:43 %2B0200." <37D41C7B.E7D715AD@scc.nl> 

next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote:
> 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.

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 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?19990907103348.2801F1CA8>