ideas and questions for implementation of MessageMode in Named Pipes

[Juan Lang]

> and no, you _can't_ do "everything in wineserver", because you _still_
> need a mechanism to be able to tell the client (ntdll) to "block".

Well, if there are two fds still, but each end is either a client
(reading or writing) and the other is the wineserver, I believe you
could.  That is, the server would only write complete messages to a
fd, presumably prepended with the length.  A reading client would then
block if there weren't any data to read, and there wouldn't be any
data until a complete message were written there by wineserver.

> which is why i asked if there was a way for wineserver to tell a
> client wine thread/process to "go to sleep" [and didn't get an
> answer].

Right.  There isn't any such mechanism, at least as far as I know.

>  _somewhere_ there has to be a "break" between "messages".
>
> and you can't stop people from sending data down the pipe (in NtWritePipe).
>
> therefore, logically, you have to have a "firewall" between "send" and
> "receive".  and, because you _also_ need "blocking on read"
> characteristics (across multiple processes and threads), the most
> sensible way to implement that is with a unix filedescriptor on which
> all of the clients (ntdll) can block.

Yep, agreed.  This discussion is more about what the structure of the
file descriptors is.  But in general, my opinion here doesn't carry
much weight, Alexandre's does ;-)  And he's unlikely to voice an
opinion except on patches.

>  well, here's the thing: you can't _guarantee_ that wine will be
> *exclusively* running on the latest-and-greatest version of the linux
> kernel, and, also, it would be a bit unfair to the FreeBSD folks (and
> anyone else who would like to port wine to other OSes)

Sure, that's true.

>  well, here's where i should explain what my goal is.  my goal is to
> "get things started".  these days i tend to get involved in free
> software projects at "critical juncture" points, where there is
> clearly cross-project non-communication and/or non-cooperation
> (accidental or otherwise), and where it's _really_ important that the
> stuff actually gets done, but is sufficiently complex and
> misunderstood that nobody really wants to tackle it.
>
>  message-mode namedpipes falls into that category, which is why i'm doing it.

And we appreciate your attention to it.  Really, we do :)

>  so - once i have _a_ working implementation, then please do not be
> offended, or surprised, if, when asked to make further enhancements,
> or if asked to fit specific criteria (such as doing things a "slightly
> different way"), i decline to do so.

Yep, that's been my assumption all along.  That's why I've nudged you
with respect to tests a couple of times.  Thanks for putting some in
the bug, by the way.  Since I assumed it was unlikely you'd have the
patience to work with AJ to get your patches accepted, I thought
having some test cases, along with an implementation that isn't
fundamentally flawed, would help point us in the right direction.
Pointing out that handles can be shared between processes was a hint
about one fundamental flaw that can trip you up.  I'll try to look at
what you're doing now and again to point out things that just can't
work.  For the most part, though, I'll assume you know what you're
doing.

> also from that strategic perspective, much as i would love to
> collaborate with steven on a kernel-level implementation of named
> pipes, i believe that it's extraneous: it's an optimisation.  and if i
> were to work on that optimisation only, as the _only_ option, it would
> lock out other possibilities.

Okay, fair enough.

> so, on balance, i'll not be contacting steven right now.  that, and
> the fact that the samba team decided to block all communication on
> 16th december 2005, and have neither revoked it nor issued a public
> apology for doing so, means that i cannot contact him _anyway_.

Well, this is a bit off-topic, but he's a Linux kernel guy, not really
part of the Samba team.  But I understand that you don't want to go
the Linux-kernel-module-only route, and I respect that.

Thanks,
--Juan