Re: WriteFile()

I don't know about you, traditionally, across every language, hardware,
platform, etc, Synchronous 100% meant a blocked call. Asynchronous mean
non-blocking augmented with some other signaling concept, be it event,
callback or message based. This is now Windows specific. These fundamental
I/O and communications principles is the basically same across all systems
and hardware and I based that on nearly 30 years experience, 20+ languages,
15+ platforms from micros, minis, hybrids and mainframes.

That has nothing to do with the fact whether there is a timeout
consideration. It may part of the equation or not.

Maybe we should use the terms Blocking vs. Non-Blocking instead.

For a blocking WriteFile() when *no timeout* is expected or the device is
prepared for *no timeout* behavior, the call is 100% blocked and there are
only two possible result:

- Success where request = written
- Error

Anything else is a unexpected design framework.

If a timeout is known to exist, then of course, it must be part of the
application design.

So in my opinion, the OP's answer is:

YES for 100% blocking design
NO for non-blocking designs.

I don't know how much simple it can get or why this is even a question. The
deviation from this fundamental rule means CHAOS in application design. I
mean, what's the point of even thinking about "blocking" if a WriteFile()
can always return unexpectedly? It means a fundamental change across the
board for thousands if not millions of applications.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






"Slava M. Usov" <stripit.slough@xxxxxxx> wrote in message
news:e1FPzzsPFHA.2356@xxxxxxxxxxxxxxxxxxxxxxx
> "Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
> news:u9XBHzrPFHA.1528@xxxxxxxxxxxxxxxxxxxxxxx
>
> [...]
>
> > Note he said, "synchronous operation" which implies block with no
> > timeouts.
>
> I do not understand how this implication comes about. Synchronous IO means
> exactly one thing: the caller will not be able to do anything until IO
> terminates, successfully, unsuccessfully, or semi-successfully. Or
> quasi-successfully, if you will. WriteFile() is a generic routine and it
> makes no assumptions as to how 'successfully', 'semi-successfully' and
> 'quasi-successfully' can be differentiated. It simply returns three things
> to the caller: general success/failure status, size of the successful
> transfer, and error code. It can do that synchronously or asynchronously.
> The rest depends on the medium involved. The caller always knows the
> character of the medium, and should interpret those three things properly.
>
> Speaking of the medium, much depends on tradition, as you say. Files are
> traditionally handled without any timeouts. Even though there are actually
> timeouts as you go down to metal, they will only trigger re-tries and
> eventually failures; timeouts and 'success' are incompatible for files,
> async or not.
>
> Communications, again traditionally, are built around timeouts. A timeout
> may trigger either 'success' or 'failure', but it takes more than binary
> logic to handle timeouts anyway, so what is actually returned as 'status'
is
> only a matter of convention; the important data are the 'size of
successful
> transfer' and 'error code'. With async IO, one can easily do without
> built-in timeouts, because the caller can always cancel IO. With sync IO,
> the caller cannot cancel IO, nor can anyone else; the only way to get rid
of
> stuck IO is to kill blocked threads, which leaks resources. The latter
means
> that sync IO becomes impractical without timeouts.
>
> S
>
>

.

Relevant Pages

  • Re: WriteFile()
    ... the caller will not be able to do anything until IO ... Speaking of the medium, much depends on tradition, as you say. ... traditionally handled without any timeouts. ... timeouts and 'success' are incompatible for files, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... the caller will not be able to do anything until IO ... Speaking of the medium, much depends on tradition, as you say. ... traditionally handled without any timeouts. ... the important data are the 'size of successful ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... the caller will not be able to do anything until IO ... Speaking of the medium, much depends on tradition, as you say. ... traditionally handled without any timeouts. ... the important data are the 'size of successful ...
    (microsoft.public.win32.programmer.kernel)