https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #183 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- something's been puzzling me for several hours, now. i reviewed the conversation so far, looking at what i wrote back in 2009, and the very useful comments and input from juan as i first developed the tests, then a first prototype, then extended the tests.
then adam came in, and we discussed the tests, and it's clear that he fully understood the importance of the multi-read and multi-write tests.
alexandre then butts in with some incredibly rude and dismissive comments, and adam is then encouraged to *privately* talk with alexandre, to "Get How It Should Be Implemented As Defined By God Known as Alexandre".
now, what really puzzled me is: why did adam not implement the full set of tests that he *knew* - from discussions with me - were critical to demonstrating full correctness (where running the python 2.7 test suite with the multiprocess module was clearly not enough).
and it occurred to me that if he had done so, he would have had to explain to alexandre why alexandre's over-ruling "I'M RIGHT LKCL IS AN IDIOT DON'T LISTEN TO HIM LISTEN TO ME I'M THE LEADER OF THIS PROJECT" dictats turned out to be wrong.
jacek, i hope that gives you some insight as to what you're up against. you're up not only against an extremely technically-challenging core strategic bottleneck where it's critical to get both high performance *and* characteristics (reliable datagrams) that *do not exist* in POSIX sockets (or they do but they're broken and highly non-portalbe), but you're also dealing with a leader whose attitude towards impartial (uncensored) criticism and constructive feedback that contradicts his "Rule Of Law" is met with what can only best be described as "spoiled brat childish behaviour".
that has, unfortunately, meant that both you and adam and sebastien and myself have all had our time completely wasted, as well as having the consequence that tens of thousands of wine users have been let down... just so that alexandre can prove that he's "in charge".
i'll reply specifically to your message later, after i've read it a couple more times. i've also thought of another couple of tests, one of which is to check if there is write-blocking (due to buffers filling up). if NT has write-blocking on message-mode named pipes, any implementations that don't take that into account are going to result in potentially critical behavioural-changes of applications.