On Thu, Feb 5, 2009 at 1:34 AM, Juan Lang <juan.l...@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.