From owner-freebsd-current Mon Sep 6 12:57:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id DDFB815C10; Mon, 6 Sep 1999 12:57:04 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from scones.sup.scc.nl (i239.ztm.euronet.nl [194.134.67.40]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id VAA28672; Mon, 6 Sep 1999 21:56:46 +0200 (MET DST) Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id VAA32150; Mon, 6 Sep 1999 21:56:43 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37D41C7B.E7D715AD@scc.nl> Date: Mon, 06 Sep 1999 21:56:43 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: current@FreeBSD.ORG, jb@FreeBSD.ORG Subject: Re: Signal changes and {,sig}{set,long}jmp References: <37D38367.C297FD64@scc.nl> <199909061607.MAA03384@khavrinen.lcs.mit.edu> <37D3FB0E.94662026@scc.nl> <199909061841.OAA03894@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > < 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 (maybe even , 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