https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #178 from Luke Kenneth Casson Leighton lkcl@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:
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!