[Bug 17195] NamedPipe datagrams need to be _really_ datagrams

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jun 1 09:01:50 CDT 2014


https://bugs.winehq.org/show_bug.cgi?id=17195

--- Comment #147 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
guys,

the work adding proper named pipes support is now five years old.  a large
number of programs critically depend on this working.  there have been four
other duplicate bugs and there are two blockers, one of which has *eighteen*
further duplicates.

i did not tackle this particular functionality without a good reason, because i
know how critical and low-level it is.  i am amazed that it was not tackled
over a decade ago when wine was first starting out.

now, one of the problems is that because it is so low-level, it is actually
very hard to even get wine executables started to the point where tests can be
run.

to make that clear: this is such low-level functionality that even *STARTING
WINE* is itself a pretty much full and complete test.

to reiterate: by the time you get to the point where the test executables can
*be run*, there will have *already* been hundreds of function calls involving
NamedPipe MessageMode datagrams.

additionally, i already pointed out that the use of sockets is not very
appropriate.  the GNU/Linux OS and the BSD OSes simply do not have the
fundamental OS-level concept of reliable streamed datagrams, and emulating them
in a single-threaded environment (wineserver) is a bitch and a half.

also, i have pointed out that to use sockets you need to make wineserver
multi-threaded.  mr alexandre jiullard has told everyone that everything that i
say is total shit, and i am not interested in educating mr jiullard.

also, i have pointed out that if you keep using a single-threaded wineserver
the only other way to properly implement reliable streamed datagrams (in a fast
manner) is to put the data into shared memory (then use fixed-length
(semaphored) message encoding via wineserver to communicate between user-level
processes where that data may be obtained).  mr jiullard has also said that
this idea is shit. i am not intereested in educating mr jiullard.

you _could_ implement streamed reliable datagrams in a single-threaded
wineserver by placing the datagram's data into files (one file per packet) and,
again, use the single-threaded wineserver to communicate with a fixed-length
(semaphore-protected) message where the datagram's data could be obtained. 
however this _would_ actually be shit, because it would be unbelievably slow.

so the summary is: we basically know where the problem lies, and it is in the
attitude of mr jiullard.  he doesn't like the fact that i have expertise in
this area.  until he gets over his psychiatric problem this bug is going to
continue to be blocked and a huge number of applications - some of them quite
prominent - will be excluded from the list of applications that wine is capable
of running.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list