Date: Fri, 05 Mar 1999 09:57:43 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> 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 Message-ID: <199903051757.JAA81871@rah.star-gate.com> In-Reply-To: Your message of "Fri, 05 Mar 1999 17:49:15 GMT." <199903051749.KAA08647@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903051757.JAA81871>