[patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sun Feb 1 16:37:55 CST 2009
> 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
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.
More information about the wine-devel