On Sat, Mar 12, 2016 at 07:48:36PM +0100, Ingo Molnar wrote: > > * Rich Felker <[email protected]> wrote: > > > On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote: > > > > > > * Linus Torvalds <[email protected]> wrote: > > > > > > > [...] > > > > > > > > Because if that's the case, I wonder if what you really want is not > > > > "sticky > > > > signals" as much as "synchronous signals" - ie the ability to say that > > > > a signal > > > > shouldn't ever interrupt in random places, but only at well-defined > > > > points > > > > (where a system call would be one such point - are there others?) > > > > > > Yes, I had similar 'deferred signal delivery' thoughts after having > > > written up the > > > sticky signals approach, I just couldn't map all details of the > > > semantics: see the > > > 'internal libc functions' problem below. > > > > > > If we can do this approach then there's another advantage as well: this > > > way the C > > > library does not even have to poll for cancellation at syscall > > > boundaries: i.e. > > > the regular system call fast path gets faster by 2-3 instructions as well. > > > > That is not a measurable benefit. You're talking about 2-3 cycles out of > > 10k or > > more cycles (these are heavy blocking syscalls not light things like > > SYS_time or > > SYS_getpid). > > Huh? The list of 'must be' cancellable system calls includes key system calls > like: > > open() > close() > read() variants > write() variants > poll() > select() > > which can be and often are very lightweight. The list of 'may be cancellable' > system calls includes even more lightweight system calls. > > I think you are confusing 'might block' with 'will block'. Most IO operations > on a > modern kernel with modern hardware will not block!
No, I just mean syscalls that may block are generally heavy operations. There may be a few exceptions (especially close in the case where it's not the last fd for an open file) but I think you'd be hard pressed to find a case where 2-3 cycles is even 0.2% of the syscall time. But my point was not to get derailed on an argument about the exact performance (non-)benefits of "saving 2-3 cycles", just to say this is not an interesting argument for one approach vs another and that it's a distraction from other much-more-important issues. > You are scaring me ... :-( I'm not sure how to interpret this, but if you really feel what I'm writing is scary/hostile I'll try to convey my ideas differently. Rich
