[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 #175 from Luke Kenneth Casson Leighton <lkcl at 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.

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