https://bugs.winehq.org/show_bug.cgi?id=17195
--- Comment #175 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- (In reply to Linards from comment #174)
Wow ... there was a lot of heat in the 2012' :)
yep - there's a long-standing history of people getting unnecessarily angry in the software libre community, and wine is no exception.
i'm able to think things through logically several steps ahead: for some reason people in the software libre world don't like that. i think probably because too far ahead they get lost, ignore the intermediate logical reasoning chain, and then think i'm "ordering" them what to do because in their mind there's no possible supporting evidence for the conclusion that's been reached.
best thing you can do linards is let them get on with it, and learn from their mistakes.
Anywhow - whats the status? Did the patches land in 1.7.31+ in upstream ?
if they're platform-specific and expecting other platforms such as freebsd to add kernel support specifically, solely and exclusively so that the current proposed patch will work, then i certainly hope absolutely not. additionally, relying on a very very specific and obscure and not very well documented implementation of TCP that happens to be present in *current* versions of the linux kernel would be extremely fragile for something as important as this feature.
basically linards to solve this properly and in a multi-platform way that's reliable, wineserver needs to go multi-threaded. the "waiting" that's needed for each named pipe can then be implemented by a thread, blocking on an internal socket exclusive to that thread. you can't let wineserver block (EVER. it would be fatal), and you can't use any other posix socket tricks because posix *specifically* doesn't have anything like NamedPipes.
there does exist a shared memory api which has very similar characteristics to NamedPipes, but unfortunately most posix implementations are not very good (because nobody really uses them). for example, all shared memory handles are global, but once they're created you can't even globally list them to find out what was created let alone find out _what_ created it! which is insane, as the only way to clean up a system of old shm file handles would be to reboot it.
now, when i mentioned that to solve this properly in a multi-platform way, wineserver would need to go multithreaded, alexandre (the paid project leader) went absolutely ballistic. he's been forcing people to explore other options, ever since.
i realise that making wineserver multithreaded is a huge step. however it's one that really should have been done right from the start. the NT kernel is pre-emptive and multi-threaded, and making wineserver *not* emulate that has some unintended side-effects that result in very obscure performance degradation in certain multi-threaded userspace w32/w64 applications. but, as a first implementation, i see no reason why the core infrastructure should not be added, but then *all* functions (except NamedPipes) made non-reentrant (as if wineserver were a single process).
so the problem, linards, is that this is a complex issue of endeavouring to implement a kernel-level feature of one OS (NT) in *userspace* of POSIX OSes (GNU/Linux, FreeBSD, Solaris) in a multi-platform portable and *reliable* way. those requirements leave you with a total of *one* way discovered and proposed so far... and that one way has been flat-out rejected by the lead developer with absolutely no discussion whatsover.
the only reason why i have continued the discussion this far is because i have absolutely no emotional or other invested interest in the proceedings. i see something, i speak up. i won't say that i don't care what people think of me if i speak up: if i happen to care what people think of me it *genuinely* takes *second place* to speaking my mind.
the rest of the people involved however have some form of vested interest in ensuring their long-term involvement with this project, and that means that they have to keep their heads down. if the leader (alexandre juillard) dictates "no, this will not happen", then for the sake of wishing to remain involved with the project, they bow to his will, regardless of the consequences.
this isn't healthy - for them, for alexandre, or for the wine project itself, but that's what they've chosen to do. you or i can provide some external insight informing everyone that that's what's happening, but ultimately linards they have to sort it out for themselves.