http://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #2 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-01-30 14:05:10 --- (In reply to comment #1)
This is a longstanding bug in our named pipe implementation. We never got around to fixing it because a) it's harder than not doing so, and b) we hadn't yet found an app that needed it.
well, there are two. one exists - python 2.7 - the new multithreading module uses named pipes in message mode - and messages are used to exchange a digest-based authentication across processes, as a cheap way of not checking the security context. the exchange is interfered with by the first _actual_ bit of data that needs to be sent being "glommed" onto the end of the last part of the authentication exchange.
so instead of 9 bytes being read "#SUCCESS#", 43 bytes are read - "#SUCCESS#firstpacket....." and thus it all goes pear-shaped.
the second one app - that doesn't yet exist - is for named pipe integration with samba. Named Pipes over SMB allow MessageMode to be set. the DCE/RPC layer (ncacn_np) _definitely_ sets MessageMode.
i saw well over 8mb of data being exchanged over one "message", at hp. they had well over 2,000 printers on one domain. it took _forever_ to complete the transfer (order n-squared) because some idiot in microsot implemented "ERR_MORE_DATA" over an MSRPC interface in the spoolss service. so it first asked for 64k, then 128k, then 192k .... all the way up to 8mb!!!
all using NamedPipes. yeuuch :)
Do the python tests depend on this being correct?
oh yeah. the entire multiprocessing infrastructure now depends critically on this working correctly. they're moving away from the posix implementation of popen(), and also moving away from all sorts of other bunged-up stuff. all in the new module "multiprocessing" which abstracts out pipe communication, forking, threading, messaging, inter-process communication, all this lovely stuff.
it's already become a major part of the python infrastructure for 2.7 and 3.0, so it's a bit of a big deal that this works.