named pipe patch

[Dan Kegel]

Bill Medland wrote:
>>Agreed.  But blocking is hard.  It may require the full rewrite of
>>wine's named pipe support the other guy is working on.
> 
> 
> It probably requires more than that; I reckon it may require a rewrite of the 
> general flushing code.  Since it has to block, I don't know where the waiting 
> is supposed to happen (in the server or in the client)

I had an idea on this -- might not be so hard after all.

>>My guess is that the data loss you were running into is the
>>main real-world issue, and the fact we don't blocking on pipe flush
>>won't be a showstopper.  Please do try my patch, and
>>let me know what you see in practice.  I'd like to know if
>>what I'm doing is even close.
> 
> 
> Doesn't seem to work, I'm afraid.

OK, I'll chuck that part of my patch then.

> Don't bother trying to hack it on my behalf, just do it for yourself.  I get 
> around it by sticking a 50ms sleep in the server before the flush; it's long 
> enough to force a process switch and for the client to read the pipe.  It'll 
> do for a few months while I am developing and hopefully the proper fix will 
> be out then.

I bet I can stick in a test on bytes in the pipe and loop appropriately.

My need has vanished -- now I'm just trying to achieve win32 compliance.
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045