-
Zebediah Figura authored
Although the test has never been observed to fail on Windows, I think the failure is genuinely a race in the test. File handles (like events) are signaled in order to mark that an I/O operation has completed. In this case the I/O operation includes manipulating data on both ends of the pipe, and as part of that may signal the other end. Internally, however, the file handle must logically happen *after* all of this processing has taken place, not least because (given the Windows I/O architecture) it is the job of the I/O manager, not the IRP handler. Since the purpose of the test is probably just to check that the file handle will be signaled after a synchronous I/O operation has completed, we may as well check it from the client thread, after we know for sure that it has. Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=54078
1a028626
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| Makefile.in | ||
| atom.c | ||
| change.c | ||
| directory.c | ||
| env.c | ||
| error.c | ||
| exception.c | ||
| file.c | ||
| generated.c | ||
| info.c | ||
| large_int.c | ||
| ntdll_test.h | ||
| om.c | ||
| path.c | ||
| pipe.c | ||
| port.c | ||
| reg.c | ||
| rtl.c | ||
| rtlbitmap.c | ||
| rtlstr.c | ||
| string.c | ||
| sync.c | ||
| thread.c | ||
| threadpool.c | ||
| time.c | ||
| virtual.c | ||
| wow64.c |