Re: WriteFile()

I am not going to get into semantics with you.. This thread has gone far
enough.

I stand by what I say and I will continue to base the high quality
engineering of my software on it. :-)

Thanks for the NIC (non-interactive chat) <g>

Later

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





"Slava M. Usov" <stripit.slough@xxxxxxx> wrote in message
news:uEcro#CQFHA.2932@xxxxxxxxxxxxxxxxxxxxxxx
"Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
news:eyhB5G6PFHA.2348@xxxxxxxxxxxxxxxxxxxxxxx
These two statements contradict with your original statement that
'"synchronous operation" [...] implies block with no timeouts'.

I don't think so. I think I have been very consistent.

Unfortunately, no. You said: "That [synchronous vs asynchronous] has
nothing
to do with the fact whether there is a timeout consideration. It may part
of the equation or not."

Synchronous means BLOCK call with no timeouts.

No. Drop the timeouts part.

A block call with timeout considerations is in effect a "poor man's
async"
concept.

It is. But with a tradition spanning decades. It is not something
"invented
by MSFT".

[...]

But again, and again and again, if you prepare the sync device,
including
serial and sockets, for no timeouts, you will get a BLOCK.

You will get just the same with some timeouts.

On a READ, you will block 100%

On a WRITE, you will get SUCCESS or ERROR

Where is the timeout if I turned it off?

If I say READ and WRITE X bytes why will the system ignore the request
without an error?

The system does not define error conditions. Reading less than x bytes
from
a file because the file is shorter than that is not an error; this is a
feature of the file system [ = medium]. Writing less than x bytes to a
socket because the peer socket has stopped receiving is not an error; this
is a feature of the sockets [ = medium]. Timeouts make that only slightly
more complex.

I do not understand what you're trying to say now. I may be missing the
whole point. I thought, originally, that you were claiming WriteFile() was
not behaving "properly", because it could return, successfully, without
writing as much as requested. I maintain this behavior is not improper
simply because there are old and well-known IO primitives that behave
exactly in the same way.

S



.

Relevant Pages

  • Re: WriteFile()
    ... >> Synchronous means BLOCK call with no timeouts. ... >> If I say READ and WRITE X bytes why will the system ignore the request ... > socket because the peer socket has stopped receiving is not an error; ... > not behaving "properly", because it could return, successfully, without ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WriteFile()
    ... No. Drop the timeouts part. ... serial and sockets, for no timeouts, you will get a BLOCK. ... not behaving "properly", because it could return, successfully, without ... writing as much as requested. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Question about howto do proper timeout checking on connections
    ... doesn't support timeouts and even return error on setsockopt. ... > Only thing needed to push a socket to the end of the ... > a lock will be needed to protect the list from corruption. ...
    (microsoft.public.win32.programmer.networks)
  • Re: GNAT.Sockets: Timeval_Duration is in milliseconds?
    ... So if you are using Windows, Microsoft's decision to screw things up ... I suppose we have to report this as a bug in GNAT though it would be ... Personally I've never used timeouts -- I've used selectand waited ... Sets with only one socket seems to be overcomplication, ...
    (comp.lang.ada)
  • Re: Question about howto do proper timeout checking on connections
    ... But, when doing this while running multiple threads, ... a lock will be needed to protect the list from corruption. ... socket to the end of the list, ... > Implementing your own timeouts is a better way of doing this, ...
    (microsoft.public.win32.programmer.networks)
Loading