Some additional notes on this topic:

My proposed patch just handles outstanding message data from the
pronter at the end of a print job what might be not sufficient!
Depending on the (postscript) print job much more message data can
accumulate (I can remember some page numbering messages for each page)
and fail the print job at an earlier stage. Maybe that's the reason
why cups socket backend checks for (and cond. reads) incoming message
data after each sent data block (8k in size), too.

- Is there an easy way to handle these incoming message data
  independently from the output stream? Output data is sent quite
  wildly spread in our source...

- Can input and output of a socket be handled by 2 different
  processes?

- Can a socket's input independently/directly drained into /dev/null,
  so the printer is satisfied that way?

Markus.