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