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: 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: WriteFile()
    ... You will get just the same with some timeouts. ... socket because the peer socket has stopped receiving is not an error; ... not behaving "properly", because it could return, successfully, without ... writing as much as requested. ...
    (microsoft.public.win32.programmer.kernel)
  • Weird behavior with either reading or write()ing !?
    ... an event is pending on a given socket. ... I am receiving a lot of read timeouts. ... another GET request on a keepalive connection). ... To test the possibility of perhaps KQueue not notifying me of data waiting, ...
    (freebsd-net)
  • 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)