No subject

[Unknown]

c0 at gsicomp.on.ca> <45A82676.1000204 at fs.ei.tum.de> <007301c736ac$5c99da10$1200a8c0 at gsicomp.on.ca> <45A838AA.9030008 at fs.ei.tum.de> <200701130306.l0D36JX8007342 at apollo.backplane.com> <45A87472.3040108 at fs.ei.tum.de> <45A879FF.8060407 at exemail.com.au> <200701130649.l0D6nE8j008759 at apollo. backplane.com> <009301c73746$cdce3470$1200a8c0 at gsicomp.on.ca> <200701132000.l0DK0QsA020885 at ap ollo.backplane.com> <00b101c738e5$dd925710$1200a8c0 at gsicomp.on.ca> <200701152301.l0FN1BR5039049 at apollo.backplane.c
 om>
From: "Matt Emmerton" <matt at gsicomp.on.ca>
Subject: Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
Date: Mon, 15 Jan 2007 20:26:50 -0500
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:users at crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users at crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: users-errors at crater.dragonflybsd.org
Errors-To: users-errors at crater.dragonflybsd.org
Lines: 43
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1168911537 crater_reader.dragonflybsd.org 833 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.users:8623

Matt,

> :A first cut of the libc-based implementation, using a (new) syscall to
> :get/set the signal its is available, and can be found here:
> :http://www.gsicomp.on.ca/~matt/dfly/ (rev3, bottom of page)
>
>     Ok, I see a few things, all easy to fix:
>
>     * sigpend is not swapped in and out.  This is the bitmask of pending
>       signals.  It stays as it is.

I misunderstood your earlier comment about the pending mask.

>     * sigmask must be adjusted by the kernel to remove unmaskable signals
>       using SIG_CANTMASK(sigmask);
>
>     * There is a naming conflict between the sigmask() system call and
>       thethe 'sigmask' identifier, but (see next item)...
>
>     * You shouldn't need a new system call anyway, the sigprocmask()
system
>       call can be used to retrieve and set the signal mask.  I recommend
>       using that.

Absolutely.  The only reason I invented a new syscall was because of my
misunderstanding above :)

>     There is one more issue, and that is an atomicy issue.  We want the
>     new signal mask to be set simultaniously with the restoration of the
>     context (or most of it).  This means that all signals must be masked
>     temporarily while restoring the context.  But don't worry about it,
>     I can handle that part as well.  It does mean an extra system call
>     but that isn't our concern at the moment.
>
>     I can fill in the missing code assembly, no problem.  If you do one
>     more rev using sigprocmask() instead of creating a new system call
>     I can then take it from there.

Code changes uploaded to website, rev4.

--
Matt Emmerton