fix for Lawson's CLOCAL problem

Alexandre Julliard julliard at winehq.com
Mon Aug 20 22:31:57 CDT 2001


Mike McCormack  <mike_mccormack at 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
julliard at winehq.com




More information about the wine-devel mailing list