On Tue, Aug 29, 2000 at 02:12:17PM +0200, Marc Lehmann wrote: > On Mon, Aug 28, 2000 at 09:20:49AM -0600, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
