[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