[Bug 17195] NamedPipe datagrams need to be _really_ datagrams

[wine-bugs at winehq.org]

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

--- Comment #53 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> 2011-12-19 14:15:04 CST ---
(In reply to comment #51)
> (In reply to comment #50)
> Yeah I realize that wine won't start if this is botched, but I consider that a
> plus: there's a built-in test case xD

 yes... but it's not a particularly good one!  the diagnostics report is
 "Wine didn't work".  or "Wine hung at startup".

 what i'm saying is: if it's acceptable to have a completely inexplicable
 termination of wine's operation, then sure, that's "acceptable".

 personally i would find that very very strange, to be working on a software
 (libre) project where it was acceptable to do this.


> FYI Alexandre says the datagram-on-SOCK_STREAM approach won't work reliably
> with multiple threads sharing the same pipe,

  preeciselyyyyyy.

 well done.

 now you know why i created one socket-pair *per message*.  it's to avoid
 *exactly* that case where multiple threads try to read (or write) to a
 unix-pipe [as the underlying implementation]

 ... and that will result in resource-starvation.

 keep going, ok?  you'll get there.  if you manage to make this work
 in the (critical) multi-threaded case, i'll be falling off my chair in
 shock.

 what _would_ solve this would be if POSIX had a NamedPipe implementation.
 no, seriously!  if the linux kernel had NamedPipe semantics, i.e.
 reliable SOCK_STREAM with datagram (fixed packet size) semantics *as well*,
 everything would be ok.

 ... but.... actually... it wouldn't be ok, because then the FreeBSD team
 would try to install Wine, and would find that it didn't work.

 basically you're stuck with what's available in "old" style POSIX semantics.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.