[patch but not quite ready] NamedPipes messagemode

[Luke Kenneth Casson Leighton]

On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton
<luke.leighton at googlemail.com> wrote:
> http://bugs.winehq.org/show_bug.cgi?id=17195
>
> with only one significant bug - some memory corruption - the semantics
> are now correct in the namedpipe messagemode patch.

 found it.  as suspected, utilising the same critical section
fd_cache_section as in ntdll/file/server.c this issue went away.  it
wasn't memory corruption at all, it was the use of the wineserver
socket to send filedescriptors using ioctls:
server_get_named_pipe_fd() was picking up a filedescriptor that was
intended for server_get_unix_fd() and vice-versa.

 so - fixed!  working!

 ... sort-of :)

 the one remaining "fly in the ointment", which i'm going to ignore,
is demonstrated by threadread and threadwrite tests: running unix out
of socketpair file handles.

 20 writes by 5 threads are queued up by e.g. threadwrite, resulting
in a whopping two _hundred_ filedescriptors being handed out. reading
this: http://msdn.microsoft.com/en-us/library/aa365150.aspx describes
how use of a NamedPipe should block on write:

"The write operation will block until the data is read from the pipe
so that the additional buffer quota can be released. Therefore, if
your specified buffer size is too small, the system will grow the
buffer as needed, but the downside is that the operation will block.
If the operation is overlapped, a system thread is blocked; otherwise,
the application thread is blocked."

ignoring the bollocks about "buffer sizes", and "buffer quotas", which
give an indication of how microsoft internally implements NamedPipes,
it's clear then that blocking the application is perfectly acceptable.

exactly how this is to be achieved is yet to be determined, but as i
keep mentioning, it's highly likely that a per-file-handle mutex is
required.

quick tests:

1) test1, shortread, send2recv2: pass.
2) reducing BUF_SIZE in the tests code to 128 works, threadread and
threadwrite: success
3) removing the interim use of ncacn_ip_tcp in SVCCTL and returning to
ncacn_np: success.
4) going back to running a simple python2.7.exe "multiprocessing"
tests, which use message-mode named pipes, the whole damn _point_ of
this exercise: success
5) running MSYS: fail.

bugger.

a veery cursory look at the output, it looks like it's a
non-message-mode pipe.  arg.  no surprise there, then.  *sigh*.

will let you know how i get on.

l.