[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 #181 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to winetest from comment #179)
> Well wine-staging has includded a series of patches related to this who
> knows how long alredy. So it's actually fixed in staging,

 ah.... from what i remember, the patches that adam wrote are based
 on a very special, unique and specific feature of the linux kernel's
 TCP/IP stack.
 in other words, they're completely non-portable.  meaning: FreeBSD
 and other OSes which did not have that specific feature.

 however... reviewing what he wrote very quickly i'm not seeing any
 evidence of the use of TCP/IP so that could have just been an idea
 that (fortunately!) wasn't used.

> but the patches
> arent merged in upstream. Can't say about the correctness of the patches.

 from a quick scan i'm seeing that there's only been one extra test added,
 which does *not* include the absolutely critical multi-thread-reader
 and multi-thread-writer tests that i created which demonstrated the
 correctness of the (excruciatingly-slow-and-brain-dead) prototype patches
 many years ago.

 i cannot emphasise enough how important it is to double-check that the
 race conditions of multi-threaded readers, multi-threaded writers
 *and* multithreaded simultaneous readers-and-writers all pass.

 this really is an incredibly obscure and deceptively complex scenario
 which is why it's been left for such a long time.  i understood it
 well at the time but couldn't possibly describe it now without spending
 significant time on it.

> But I have pretty much deep trust in Slackner's work.

 that's a very good sign.  i do have to say though that this particular
 scenario is about as complex as the threading library implementation
 that had to go into wine (which is identical to that of the freedce
 threading implementation which i'm also familiar with), and it has _that_
 much of a low-level impact, not least because it's part of the
 MSRPC infrastructure (NamedPipes *are* the means by which MSRPC
 communicates).

 so if you get this wrong you *can't even start up wine* which is as
 good a test as any... *but*... because wineserver is single-threaded
 it's very very deceptive (i.e. insufficient).  i recall suggesting
 adding (and using) a separate implementation of ncalrpc as a means
 to bypass this limitation, so that at least the WINREG and other
 critical infrastructure on which the tests rely can get up and
 running... but anyway.

 so, trust is great... but i would strongly suggest adding the required
 tests *before* proceeding further.  that gives an objective benchmark
 which everyone can double-check, very easily.

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