Catastrophic blocking

[Thiago Macieira]

On quarta-feira, 29 de fevereiro de 2012 11.50.10, Kristian Hoegsberg wrote:
> which handles the problem you hit.  The connection code polls for
> writable just fine and only writes when the fd returns EPOLLOUT.
> Except in the above case, which is where it typically happens.  When
> the protocol buffer is full, we write without checking for writable,
> and after a while that hangs.  One option would be to just kill the
> client if the protocol buffer overflows, but that doesn't leave the
> client a lot of rope.  Also, aparently an fd can be "spuriously
> writable", that is, even if we get EPOLLOUT, writing to it may still
> block.  That sure seems like a bug to me, but if we pass MSG_DONTWAIT
> to sendmsg we guard against that and can fill up the kernel buffer
> before we kill the client.

MSG_DONTWAIT is Linux-specific. Why isn't the socket in non-blocking mode in 
the first place? Is there any problem with that?

I know there are other non-standard flags too, but they can all be handled by 
setting to 0 (MSG_NOSIGNAL, MSG_CMSG_CLOEXEC) and taking further action.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120229/c3dd8935/attachment.pgp>