On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton luke.leighton@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! done! 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.