named pipes improvements

[Antoine Martin]

Follow up from #1150

• use the "socket-dir" as named pipe path (currently hard-coded to Xpra\) and use the "socket-dirs" as the list of named pipe paths we search
• shadow server crashes easily with debug logging (could be the same issue as #1149)
• non-trivial clients (ie: xpra attach) cause garbage to be received by the server

[Antoine Martin]

Milestone renamed

[Antoine Martin]

trying to not deadlock

[Antoine Martin]

r13735 is enough to be able to use "xpra info" and "xpra version" against a local win32 server (ie: "xpra shadow"), but not enough to connect as a client: when it doesn't deadlock on the named pipe, it seems to choke on the "logging" packets? (could be an encoding issue)
"xpra stop" kinda works, but again you need to run another command to get the named pipe thread to exit.
It's a mess and I really don't have time for this awful Microsoft API style.

[Antoine Martin]

Named pipe code is currently broken by the move to ctypes (#678).
If this cannot be fixed in time, the named pipe code will have to be disabled.

[Antoine Martin]

ctypes implementation that doesn't crash! (also doesn't work..)

[Antoine Martin]

can connect and read the packet.. but we need overlapped IO to both read and write without blocking, oh joy

[Antoine Martin]

Done in r15179. That was hard.

Some pointers that led me to the solution:

• ​Usage of overlapped named pipe for simultaneous read and write on Windows: All you need to do is to provide a different OVERLAPPED structure to each of the simultaneous operations.
• ​GetOverlappedResult

---

This also adds the "-d named-pipe" debug flag.

What this feature does: we can now query a running shadow server ("xpra info", "xpra list", "xpra version", "xpra stop", etc..) and even attach to it over named pipes. Follow up in #1454

@afarr: this is a FYI, feel free to close.

[maxmylyn]

Acknowledged, and closing.