Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/14/1999 11:10:24
>>> * fixing it wastes both kernel code space and pipe() execution
>>> cycles. granted, not much of either, but some of each.
>> If `fixing it' means calling socketpair() from userspace and doing
>> any necessary frobbing there, it actually means *reducing* kernel
>> size (...and relegating pipe(2) to COMPAT_14).
If you go back and read the context, I think you'll find it pretty
clear that "fixing it" refers to making pipe(2) an ordinary syscall,
not one with special userspace goop, and in particular making it
consistent with other syscalls-taking-pointers wrt invalid pointers
(ie, EFAULT rather than SIGSEGV).
> pipe(2) is defined to be one-way. socketpair(2) creates a two-way
> I didn't find any obvious way in the manual page to suppress one of
> the ways. Hm. The libc wrapper could partially shutdown(2) the
> ends, I guess....
Yeah. Which would mean that pipe(3) would take three syscalls instead
of the one it presently takes. Whether this would matter, of course,
is another issue.
For that matter, I can't help wondering how many programs would care if
pipe() returned a bidirectional pipe. Portable code couldn't rely on
it, obviously, but portable code is unlikely to do anything that cares
whether the pipe is bidirectional or not.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B