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