DragonFly users List (threaded) for 2007-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
[no subject]
c0@gsicomp.on.ca> <45A82676.1000204@fs.ei.tum.de> <007301c736ac$5c99da10$1200a8c0@gsicomp.on.ca> <45A838AA.9030008@fs.ei.tum.de> <200701130306.l0D36JX8007342@apollo.backplane.com> <45A87472.3040108@fs.ei.tum.de> <45A879FF.8060407@exemail.com.au> <200701130649.l0D6nE8j008759@apollo. backplane.com> <009301c73746$cdce3470$1200a8c0@gsicomp.on.ca> <200701132000.l0DK0QsA020885@ap ollo.backplane.com> <00b101c738e5$dd925710$1200a8c0@gsicomp.on.ca> <200701152301.l0FN1BR5039049@apollo.backplane.c
om>
From: "Matt Emmerton" <matt@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@crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: users-errors@crater.dragonflybsd.org
Errors-To: users-errors@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
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]