ideas and questions for implementation of MessageMode in Named Pipes

[Luke Kenneth Casson Leighton]

ok, alexandre: i tried moving named_pipe_read into wineserver - it's
not possible to do completely, as you cannot do blocking-reads in
wineserver but you still need blocking-read characteristics in the
client (kernel32, ntdll).  if you start messing with the fd, setting
or clearing ioctl O_NONBLOCK in one, it interferes with the other.
there's a race-condition risk.

so, i have some ideas and questions.

1) is it possible for wineserver to tell a thread to wait
indefinitely?  is there a communication channel where wineserver can
tell "anyone who's interested" to go away, go to sleep, i'll tell you
when to wake up"? what i want is to replace the fd blocking-read with
something that still blocks, but doesn't interfere with the file
descriptor.

2) would a _second_ filedescriptor fit the required criteria, as
described in 1), above?  in other words, if the message-lengths (4
bytes) were sent on a secondary control fd - and nothing _but_
message-lengths were sent on that fd - my intuition tells me that that
could work, even without having any infrastructure in wineserver.  in
fact, i get the feeling that it would be _better_ - and a lot simpler
- than having any infrastructure in wineserver.

the reasoning goes roughly something like this:

* 5 threads are waiting - blocking - on a message-mode read named
pipe.  all of them are blocking to read from the "control" channel, in
userspace (kernel32/ntdll).

* client 1 does a message-mode write, and in userspace
(kernel32/ntdll) 4 bytes indicating the length of the message are
sent, followed by N bytes on the unix_fd (exactly as is done at the
moment).

* one and ONLY one of the 5 threads, thanks to STANDARD linux kernel
scheduling, happens to be awake and gets to read the 4-byte length.
all the other 4 stay asleep.

damnit, that's not right, is it.  you want the other 4 to wake up once
ONE of them has read the 4-byte length, and for ALL of them to move on
to blocking on the "message" pipe - the actual content.

so, i suppose what you could do is have a per-read-thread
filedescriptor (!!!) which _would_ have to involve arbitration by
wineserver, so that when a write is performed, ALL of the clients get
notified "wake up now, start trying to read".

is there _anything_ in wine which already exists that does what is
required, as illustrated, above?

answers and information greatly appreciated so as to be able to
improve this free software project's effectiveness.

l.