[patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)

[Luke Kenneth Casson Leighton]

> so, adding server_named_pipe_read() avoids this issue by doing locking
> (like server_get_unix_fd()) does, i see)

 $ git commit -a -m '#17185 - server-based read_named_pipe.  does
blocking in client and non-blocking reads (using recv MSG_PEEK) in the
server. messy as hell.'

says it all, really :)   bit of a marathon session that one.
break-time.  more in a couple of days.  anyone want to take over,
email me, you can have what i've got so far.  blocking checks
client-side (using select) are made on the unix-pipe fd to ensure that
there's _actually_ data that wineserver can get at.  after reading the
message-length (done only once per message duh),  read() is replaced
by server_named_pipe_read() - still in the for (;;;) loop.

alexandre, would it be reasonable to put a CriticalSection around the
[optional message-length-reading and] for-loop?  i really can't see
any other way.  what i've done is protect the server from blocking on
a read(), by making sure that recv(MSG_PEEK) - actually select() might
be better - checks the length.  that means however that you still, in
kernel32, in ReadFile(), still have to do the for() loop, but
preceding each read by a blocking wait (i clear O_NONBLOCK and do an
infinite/blocking select())

it all screams "CriticalSection" protection - on a per-handle basis.

anyone got any better ideas?  let me know, i'll come back to this in a
couple of days.

l.