[Bug 17195] NamedPipe datagrams need to be _really_ datagrams

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=17195

--- Comment #166 from Sebastian Lackner <sebastian at fds-team.de> ---
Hi,

@Adam: The main advantage of using the wineserver is that such a solution is
platform independent. Nevertheless your approach had several disadvantages -
writing was always nonblocking, it was theoretically possible to flood the
wineserver with too many messages, so that no further memory can be allocated,
... besides that it didn't follow the wineserver style convention, and used
wrong or no error codes at some places, but thats easy to fix of course.

If we want to use a wineserver solution, then we have to do a lot more work, to
implement everything properly (blocking writes, but different partial writes
after each other shouldn't result in interleaved output, ...). I personally
would prefer having a kernel solution, but at the end its not really my
decision. The next step will be to get all my >1000 lines of additional tests
upstream, and talking to some kernel developers in the meantime.

Encoding the "end-of-message" flag in the data stream is not possible, since
you have no control how many bytes are returned ... unless you do a peek first,
but then its subject to race conditions.

@Luke: One socket pair per message also doesn't sound like a good solution,
what about weird programs sending one byte after each other? Moreover in byte
read mode the messages have to be merged again, which would also lead to race
conditions, when NtReadFile only operates only on one socket at a specific
time.

I have also no idea why you think its not possible to implement "blocking"
behaviour in the wineserver. It is possible of course, and in fact used already
in some places, it just works by allocating a wait handle, and then temporarily
returning control to the application. While inside a wineserver call no APCs
can be handled, so it wouldn't be a good idea anyway, and wouldn't even work in
a multithreaded environment. A multithreaded wineserver would be good for
performance reasons, but it makes a lot of other things much more difficult,
and I doubt that anyone would be able to change all that without introducing
new regressions.

And, it was already said multiple times: Please just leave out all your insults
and anger, this bug report is not the right place for that. Even if you have a
different opinion, you have to accept that Alexandre is the maintainer, and he
decides which features are good enough to included in the official version.
Noone keeps you from adding experimental features in your own builds.

Regards,
Sebastian

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