From owner-freebsd-current  Tue Sep  7  3:34:28 1999
Delivered-To: freebsd-current@freebsd.org
Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1690814D09; Tue,  7 Sep 1999 03:34:22 -0700 (PDT)
	(envelope-from peter@netplex.com.au)
Received: from netplex.com.au (localhost [127.0.0.1])
	by overcee.netplex.com.au (Postfix) with ESMTP
	id 2801F1CA8; Tue,  7 Sep 1999 18:33:48 +0800 (WST)
	(envelope-from peter@netplex.com.au)
X-Mailer: exmh version 2.0.2 2/24/98
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 
In-reply-to: Your message of "Mon, 06 Sep 1999 21:56:43 +0200."
             <37D41C7B.E7D715AD@scc.nl> 
Date: Tue, 07 Sep 1999 18:33:48 +0800
From: Peter Wemm <peter@netplex.com.au>
Message-Id: <19990907103348.2801F1CA8@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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