Some interesting reads:

    -- "A history of S_IFMT":
       http://www.lubutu.com/soso/a-history-of-sifmt

    -- "TASK_KILLABLE":
       http://lwn.net/Articles/288056/

    -- The syscall "signalfd()" which was new to me (whoops):
       http://man7.org/linux/man-pages/man2/signalfd.2.html

    -- Why "signalfd()" doesn't solve your problems either:
       https://ldpreload.com/blog/signalfd-is-useless


                           ____________________


  I spent the better part of the weekend experimenting with PulseAudio.

  I've  always  avoided  PulseAudio  as  best  as  I  could.  It's a big
  application  and  people  say  it  causes  a  lot  of  problems.  Most
  importantly,  plain  ALSA  worked  okay for me. I have a pretty simple
  setup (just a soundcard and speakers) that doesn't change  a  lot.  So
  why bother?

  Recently,  I  wanted  to  use  HDMI audio. It took me about an hour to
  write an asoundrc for that purpose. Oh, right, I  explicitly  disabled
  HDMI audio before because it was getting in the way.

  I  also  wanted  to  make use of some bluetooth speakers, but I didn't
  even try to get them working.

  Okay, let's just give PulseAudio a try.

  It works a lot better than I expected. No stuttering, no high latency,
  no  crashes  (yet).  The  feature  set is nice. All applications, even
  older ones that use OSS, still work. I think I'll keep it.

  Of course, I'd much rather use a simpler sound stack. Right now, sound
  goes  from  the  application through some wrapper library (like libao)
  through userland ALSA (maybe) which then routes it to PulseAudio which
  finally routes it to kernel ALSA. That's crazy.

  I agree with many points made in this blog post, even though it's from
  2009:

  http://insanecoding.blogspot.de/2009/06/state-of-sound-in-linux-not-so-sorry.html

  But then again, I'm tired of manually writing some asoundrc when I can
  achieve the same goal using PulseAudio with just a few mouse clicks or
  pacmd commands.