Juan Lang <[EMAIL PROTECTED]> 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. -- Alexandre Julliard [EMAIL PROTECTED]
