named pipe patch
dank at kegel.com
Tue Apr 22 12:14:23 CDT 2003
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.
More information about the wine-devel