Comment 78 for bug 386326

Axel, thanks a lot for your very helpful analysis.

Let me describe the scenario, combined with SSL/PSM state

- application code talks to the PSM I/O layer,
  which talks to the NSS libSSL I/O layer

- the described bug happens after libSSL has signalled a short write,
  some bytes not yet flushed out to the socket

- libSSL expects that we call "write" again,
  giving it a chance to flush

- when we arrive in this state,
  PSM reports to the application level "-1 bytes written, would block"

- when the application level calls (write) again,
  PSM calls into libSSL, trying to flush

  I don't know what happens if libSSL is still unable to flush,
  as it appears to be in this bug scenario.

  I suspect it will tell us "would block".

- when the application level polls, while we are in this
  "short write, need flush" mode,
  the PSM layer will always signal "writeable" to the application level.

  It's done this way, because apparently when I wrote the code,
  I didn't know of a way to ensure we'll wake up, once the socket becomes
  writable again.

- Axel tells us, the application code constantly polls and attempts to write
  never succeeding, resulting in a deadlock.