[Bug 17195] Multiple applications and games need support for named pipe message mode (NamedPipe datagrams need to be _really_ datagrams)

[wine-bugs at winehq.org]

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

--- Comment #178 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacek Caban from comment #177)
> Since commit b682e1c41d89c9303d30312c83a402d0cdee4ece, we have support for
> message more writes (NAMED_PIPE_MESSAGE_STREAM_WRITE). A patch for reads
> (NAMED_PIPE_MESSAGE_STREAM_READ) is on its way:
> 
> https://source.winehq.org/patches/data/131854

hi jacek,

ok first question: i assume that both patches have had some form of
review and discussion?  if so, where is that taking place so that the
(increasingly large - 54 at the present time after 9 years) list of
people interested in seeing this be fixed can get involved, make
comments and so on?

second, from looking at the patch i have an immediate question: i assume
that you have some code outstanding: have you run the tests that are
attached to this bugreport in order to confirm that the known
race-conditions outlined in the majority of proposed implementations
are catered for?

specifically: when multiple threads are set up to read and multiple
threads are set up to write to the exact same pipe, the windows w32
API has "locking" around the length-data tuple which absolutely
guarantees that only one reader will have access to the actual pipe.
otherwise, what happens is: one reader reads a little bit from the
pipe thinking it's "data", and it happens to *INCLUDE* the length!

likewise when there are multiple writers, you get an overlap of
length1-length2-data1-data2 or worse length1-part-of-data1
length2-part-of-data2-part-of-data1-part-of-data2

can i suggest reading *carefully* (ignoring the various people who
keep thinking i'm being a fucking idiot), the whole of this bugreport
as it really is extremely complex.

basically the only solutions that will actually work in a cross-platform
way are: (1) shared memory (which has been ruled out in an extremely
rude way by julian but despite that i firmly agree with him: globally
shared memory can't be recovered / reopened if an app closes) or
(2) wineserver has to go multi-threaded in order to handle the
"blocking" semantics.  unfortunately, here *yet again* julian has
(in an extremely deeply unimpressively rude way) flat-out said "no"
with absolutely no explanation as to why.

and that's really all that you need to know about why this bug is now
eight years old, and despite being Priority 2 and is the cause of
several critical programs failing, still hasn't been fixed, because the
*actual* problem is nothing to do with programming or source code:
the *actual* problem is a systemic failure of wine's interaction with
"outsiders".  there was a report on slashdot well over 10 years ago about
this and it still hasn't really been resolved.

ah well.

anyway if you're brave enough to face up to that, then you'll do okay,
and i'll be honoured to help advise on a proposal that, in the many
years since this was raised, i believe may actually work in a
cross-platform way which might actually be acceptable (and, later,
could be adapted to improve wine and fix some of the  extremely
obscure performance bugs).

as always: feel free to ignore my input and advice if you so choose,
but bear in mind that in doing so you directly take all responsibility
for the consequences.  this is *very* low-level and great care has
to be taken to ensure that it really, really is technically correct.

also, you may be aware that once it *is* fixed, a whole slew of
other errors will crop up, not because this bug *isn't* implemented
correctly but because it *IS* implemented correctly.

if you implement it wrongly it is the worst of all possible worlds...
so be really *really* sure ok!

-- 
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.