ideas and questions for implementation of MessageMode in Named Pipes

[Luke Kenneth Casson Leighton]

On Thu, Feb 5, 2009 at 1:34 AM, Juan Lang <juan.lang at gmail.com> wrote:
> Hi Luke,

 hi juan, thanks for responding.

>> how about: ripping out the use of unix-pipes altogether, and replacing
>> them with tdb (trivial database) in a mmap'd file?  the nice thing

> The usual response around here is, show us some patches, and we'll let
> you know ;-)

 yehh, ha ha :) i was kinda hoping to not have to go through five
different implementations!

i think i've finally come up with an idea that i believe will work:
double-socketing.

very simple: you write down one filedescriptor, and read from a
different one.  wineserver proxies the data from one to the other,
whenever it's requested.  here's the important bit: wineserver ONLY
allows ONE lot of data into the "read" socket at any one time.

it'll be ok (and desirable) to allow multiple "readers" of the "read"
socket. what you _don't_ want is more than one reader trying to
indicate "please start sending a new message" whilst there are other
reader(s) still grabbing the previous message.

so i believe that a critical section (copying the style of the code
around server_get_unix_fd) each around "please start a new message"
and "please send some more read-data" would be sufficient.

what do you think?

also the advantage of double-socketing is that when it comes to doing
SMB named pipes there will be a clean "way in and out" for SMBreadX,
SMBwriteX and SMBtransactNamedPipe data over the IPC$ share.  the
double-sockets will still be needed (one for reading, one for writing)
- a _third_ socket will be needed, to communicate with the smb server
(via the break-out mechanism).



> Some test cases showing us where we're deficient would be a great start, btw.

 all there, in #17195.  five so far.

* test1 (the first i wrote) just does send recv send recv.  this one
works (in existing wine)

* send2recv2 does send send recv recv and it's this one that shows
_immediately_ that there's a problem with wine's messagemode code.

* shortread demonstrates the "standard" way to be able to read blocks
of data when the message is _way_ beyond acceptable incoming buffer
sizes (e.g. in smbs it was often the case that spoolss would result in
SMBwriteX SMBwriteX SMBwriteX SMBtransactnamedpipe SMBreadX SMBreadX
SMBreadX transferring _whopping_ great sized messages).  again, wine
keels over on this one as it doesn't know what to do at the message
boundaries.

* threadread demonstrates several messages being queued followed by a
number of threads performing simultaneous reads (deliberately using
shortreads where the individual reads are fixed sizes).  i only have
this doing 1 thread at the moment because the data needs to be
"reconstructed" properly otherwise (even on nt).

* threadwrite demonstrates several messages being written
simultaneously, with a single process grabbing them all.  this one
_doesn't_ have to be limited in the number of threads that perform
writes, which indicates in the internal design of NT that the writes
are atomic.