Juan Lang juan_lang@yahoo.com writes:
Again, why? The named pipe server has to support multiple accesses, so multiple processes can create unique connections to the same pipe, and let the server worry about concurrency. Even if that weren't the case, using a synchronization object and shared data in the wineserver would be able to control access. In the multithreaded case, you only need to implement concurrent control in the dll that implements named pipes (most appropriately ntdll). I had to synchronize NetBIOS receives across threads in netapi32.dll, and this doesn't seem any harder.
You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something.