Linux could have adopted kqueue, but instead has spent the past 10 years slowly reimplementing every feature. In some cases, reimplementing it multiple times. Linux is asymptotically approaching kqueue.
The BSDs, OTOH, rarely have a problem adopting useful Linux features. The most recent example are extended pipe(2), socket(2), and similar calls which allow specifying, e.g., O_CLOEXEC at descriptor creation time to eliminate the fork race with multiple threads.
BSDs are also converging on O_NOSIGPIPE, which is almost identical to the above, but which Linux refuses to adopt for no good reason other than obliviousness, or a severe aversion to adopting things not invented in Linux-land. Instead Linux only has MSG_NOSIGNAL, which only works with the send and recv syscalls, requiring old-style signal masking tricks for real-world code.
People who are predisposed to not caring about anything but Linux always frame the portability issue in negative terms--e.g. POSIX is useless because it's anachronistic and nobody supports all of it anyhow. That attitude is part of the problem. Portability is about keeping the lines of communication open, and actually seeing value in changes which ease porting software. POSIX is just one part of that. Portability done right improves everybody's software--both kernel and application.
Posted Nov 15, 2012 22:08 UTC (Thu) by alexl (subscriber, #19068)
[Link]
O_NOSIGPIPE would be very very nice. It would be awesome if linux could pick that up.
Quotes of the week
Posted Nov 15, 2012 22:14 UTC (Thu) by alexl (subscriber, #19068)
[Link]
I would also love xstat/fxstat. It almost seemed to happen with David Howells last push, but it seems to have died out... :(
Quotes of the week
Posted Nov 16, 2012 6:41 UTC (Fri) by krakensden (subscriber, #72039)
[Link]
My only experience using a kqueue semi-replacement on Linux is inotify, but... *christ* it was nice compared to kqueue on Darwin, with no unsolvable race conditions either.