I am trying to figure why it is difficult to understand the main point.
Are you an software engineer? applications developer? systems developers?
driver developer? all of the above?
That is not to demean you, not at all. But I have to approach each one
differently and seems to me that some very fundamental engineering concepts
is not being understood.
If you design a I/O application with the concrete design criteria that there
be no timeout and no overlapped I/O, then the I/O is basically working in
synchronous blocked mode.
Under sync, no timeout whether that means the device is known to have no
timeouts or you programmatically set the device timeouts values using some
known function (i.e, SetCommTimeouts), in this case, WriteFile() will block
and 100% of the time return:
- TRUE with request == written, or
- FALSE with extended error
There is NO other expectation.
What you seems to be suggesting that this basic fundamental idea for WIN32
is erroneous because indeed it is very possible to return TRUE with written
< request regardless of the device and/or its device capabilities and/or
programmable device attributes.
If this is true, then you need to come to understand and realize the extreme
ramifications this will have in current Win32 I/O software design working
under these basic fundamental premises. It is fundamentally important to
understand this point.
Now, by no means, this does not suggest that you don't need to check the
values when WriteFile returns TRUE. Absolutely not.
What I am saying is that if this is the case, where you have:
// Sync, No Timeout expected
if (!WriteFile(h,buffer, request, &written, NULL) && request &&
written)) {
ReportCrtiicalError("Fail to write requested amount",
GetLastError());
return FALSE;
}
then it represents a serious design flaw and/or hardware operation on the
machine (device) that will require a different course of software
engineering actions.
It will introduce new design consideration:
1) Replace all WriteFile() calls with a wrapper WritFileFlush() function
2) What are the retry limitations?
3) How do you find out what is the real error?
4) What final actions do you do if you can't complete the request?
Lets assume that this is ok, and you indeed do all the above, there two
ultimate results:
1) Success
2) Error
Success means that the retries and flushing eventually succceed, the device
finally "caught up" with whatever was delaying the writes.
Error means that after some unknown time limit or retry, the request was not
completed. In this case, all you can do is give the user some form of a
"critical error" action. This is great. No problem. It should be like
that.
Well, if this is the design possibilities, why not just completely redesign
the entire thing under an asynchronous, overlapped I/O framework? Why
bother with non-async WriteFiles at all? In effect, what you are saying is
that sync WriteFile() is obselete.
The fact is that asynchronous WriteFile() operatons is not required for all
designs or application needs. Any short of completing the request is an
error.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Post by Slava M. Usov[...]
Post by TerryThe question is: if WriteFile() returns no-error, was all of the
requested-data written?
Not necessarily.
Post by TerryDo we need to check that "nNumberOfBytesToWrite ==
*lpNumberOfBytesWritten"?
Yes.
Post by TerryIf WriteFile() returns error, we know we need to check those numbers
-- the question is, do we need to check the numbers if WriteFile() returns
success?
It is exactly the other way around. If it returns error, then you needn't
check the numbers -- you know it failed, so it cannot have written all the
data. The numbers need only be checked when it succeeds.
Post by TerryAs has been pointed out, a lot of software would break (as described by
Hector Santos elsewhere in this thread) if this semantic was not
implemented.
Not necessarily. WriteFile() may or may not write less than requested. That
mostly depends on what the application does. When you write files, it is
extremely unlikely it will write less and return success.
[...]
Post by TerryBecause the doc on fwrite() says that the amount-written may be less "if
an error occured", this implies that if an error did not-occur, the
amount-written will not be less than requested.
fwrite() is irrelevant. Read the docs on WriteFile() if you want to know
what WriteFile() does. If you're looking for analogies, then look at
_write(). _write(), unlike fwrite(), deals with low-level IO, same as
WriteFile().
S