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