On Tue, Aug 29, 2000 at 02:12:17PM +0200, Marc Lehmann wrote:
> On Mon, Aug 28, 2000 at 09:20:49AM -0600, yodaiken@fsmlabs.com wrote:
> > You can't rely on signals timing anyway -- that is quite clear in the
> > spec and in the implementation.
>
> there is no "spec" on how it should be done. Again, it is about security and
> "doing it as right as possible" and not "according to POSICKS we can do
> whatever we want".
Implementing signals with good worst case
timing seems very implausible to me. We don't even
have timing guarantees for signals in RTLinux where the kernel is simple.
The main reason is SMP -- if the target thread/process is running on a
second CPU, you need to send a IPI and then have the remote processor
run signal code. But ipis are relatively slow and the remote processor
may have interrupts disabled and ...
>
> Just necause some standard says we needn't does not mean that we could do
> it better.
>
> > Especially on a SMP machine, STOP has weak semantics and I don't see how
> > to imrove it.
>
> It is possible to get "good enough" semantics with the
"good enough" for security?
On processor A a SIG_STOP is issued to a thread-group while on processor
B a thread element has just entered write. How many bytes written is
"good enough".
I've really exceeded my quota for this news group and will respond
privately if you want to continue.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:23 EST