Messages in this thread | | | Date | Sat, 12 Mar 2016 19:48:36 +0100 | From | Ingo Molnar <> | Subject | Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers |
| |
* Rich Felker <dalias@libc.org> wrote:
> On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote: > > > > * Linus Torvalds <torvalds@linux-foundation.org> 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!
You are scaring me ... :-(
Thanks,
Ingo
| |