From owner-freebsd-hackers  Fri Mar  5  9:59:35 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138])
	by hub.freebsd.org (Postfix) with ESMTP id 4588C14A2F
	for <hackers@FreeBSD.ORG>; Fri,  5 Mar 1999 09:59:32 -0800 (PST)
	(envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id JAA81871;
          Fri, 5 Mar 1999 09:57:43 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199903051757.JAA81871@rah.star-gate.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Terry Lambert <tlambert@primenet.com>
Cc: dyson@iquest.net, dick@tar.com, jplevyak@inktomi.com,
	hackers@FreeBSD.ORG
Subject: Re: lockf and kernel threads 
In-reply-to: Your message of "Fri, 05 Mar 1999 17:49:15 GMT."
             <199903051749.KAA08647@usr06.primenet.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Mar 1999 09:57:43 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

You are right !

However, I was thinking about the set of signals which user has available to 
use .

SIGFPE, SIGIO, etc...

	Amancio

> > I supposed that for a limited distinct events signals are really cool.
> 
> No, they aren't.
> 
> Signals are persistant conditions, not events.  Otherwise I would be
> able to count them accurately.  Right now, I can be counting one of
> them, queue another of the same signal, and all subsequent signals
> of that type are dropped on the floor.
> 
> 
> > If you can deliver a signal there is nothing to stop you from
> > delivering an AST provided that one can muster up the queuing
> > delivery mechanism which is not that much different than the
> > beloved old fashion signal delivery mechanism.
> 
> Actually, AST's run in a mode between supervisor and user.  The x86
> handles this (the infrequently used "ring 1" and "ring 2", but other
> processor architectures do not.
> or previous employers.

Thats a kernel implementation issue and not necessarily a platform specific 
feature assuming
that the platform can do multitasking .

	Cheers,
	Amancio





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message