--- Alexandre Julliard julliard@winehq.com wrote:
In the remote case, what we need is for the kernel to manage the whole protocol, so that we can do read() and write() calls as if it were a normal socket. You cannot manage the protocol in the client process, it breaks down as soon as two threads (or worse, processes) share the same pipe.
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.
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003