Mike McCormack mike_mccormack@start.com.au writes:
Hmmm. i'm not exactly sure about this. i don't think the server ever blocked on serial port reads or opens... i think the reason Lawson had problems was that the client thread was blocking in the overlapped read code. (FILE_AsyncReadService in files/file.c)
I don't know if this was Lawson problem, but open() can potentially block on a serial port, and we cannot have that in the server; so your change to set O_NONBLOCK is good, but it shouldn't depend on FILE_FLAG_OVERLAPPED.
If we use non-blocking fds unconditionally, a non overlapped ReadFile may result in a busy loop in the client thread.
Sure, you need to reset the O_NONBLOCK flag to do blocking reads.
Additionally, overlapped read (and write) requests should fail unless the handle is opened with FILE_FLAG_OVERLAPPED. There are programs that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on this list). This is another reason to propagate CreateFile's attributes parameter into the wineserver.
Of course, I have no problem with that. The create_file request takes attributes, so create_serial can do the same (it would be better if create_serial were done inside create_file, but that's another story...)
Another question: do you think it would be possible to implement a "write memory" message from the wineserver to the client? This message would be carried over wait_fd and would be received by the client asynchronously in wait_reply(). The message would contain a length, address and data to be written. If this is possible, i could move async i/o back into the server, keep it efficient and perhaps implement CancelIo properly...
But that would require multiple copies of the data (and many context switches for large reads); that wouldn't be very efficient. I think the current approach is much better. What is the problem with doing CancelIo?
-
Alexandre Julliard