Re: f0dder's Fabulous Wait States.

> The argument on the dependence on polling technology cannot be lost
> for a very simple reason, with Von Neuman architecture (read
> SEQUENTIAL ACCESS TO INSTRUCTIONS AND MEMORY), current x86 processors
> just keep doing "one damned thing after another" but they do it very
> fast and with hardware support for task switching so it tends to LOOK
> LIKE parallel actions occuring at the same time.
>
> Herein lies the scale of f0dder's confusion.

And your point is? Forgot about hardware interrupts, perhaps? Ah yes,
you think "interrupt" has something to do with prevention :)

>> ReadFile, GetMessage, WaitFor*Object, and a lot of other functions,
>> are all blocking (with the exception of ReadFile in OVERLAPPED mode).
>
> ReadFile() with normal flags does not return until it reads the data
> into the supplied buffer, GetMessage() does not return until a message
> is available and the Wait state APIs set a system defined wait state
> and don't return until the condition has been signalled. The attempt
> to generalise across 3 entirely different function types is the
> indication of the level of confusion that f0dder suffers with system
> API calls.

....and the three of them have in common that they use blocking wait.

> Now f0dder wants to change the subject from the viability of system
> defined Wait states to a redefinition of the term "Block(ing)" so that
> anything that does not return is a blocking function.

No - anything that does a blocking wait are blocking. This is a pretty
well-defined term.

> ================================
> Uh... no. Not that your sentence made much sense. If you're going
> to make statements about the internal workings of windows, at
> least do yourself the favor of reading "Inside Windows 2000".
> ================================
>
> Even f0dder should know by now with his penchant for having
> consultations with the "colonel" that this data is out of date. None
> of the available lists of int 2Eh services are correct for the
> version of win2000 SP4 I use because Microsoft intentionally change
> them from version to version to slow up the idiot fringe with trojans
> and viruses.

So? "Inside Windows 2000" doesn't list int 2E service numbers, it
describes the general architecture the NT system is based on. One of
the authors of the book is from SysInternals (you know, the guys that
made process explorer among other things), and it's published by
Microsoft Press (those guys really *ought* to know something about the
operating system).

If you read that book, you'd know what "blocking wait" means. And you'd
know that *this* is the basis for the OS, not polling loops. You would
also know that ReadFile is implemented ontop of the asynchronous native
NT API file operation, and that it does a blocking wait to "not return
until file data is read"... among other things.


.

Relevant Pages

  • Re: How to perform a non-blocking synchronous ReadFile call/operation with NDISPROT ?
    ... However there is no mention of "non blocking" synchronous I/O. ... When reading from a communications device, the behavior of ReadFile is ... You can examine the queued packets without blocking. ...
    (microsoft.public.development.device.drivers)
  • Re: The Tcl notifier and Console on Windows
    ... ReadFile is expected to be used in blocking mode. ... The notifier itself does wait in an APC compliant ... All that's really important is that when the channel becomes serviceable ...
    (comp.lang.tcl)
  • Re: about serial port communication and new operator
    ... It is unreliable to assume that you will receive a fixed number of bytes from ReadFile. ... if settings are wrong or the cable is disconnected a blocking call willl cause your entire program to lock up. ... It is best to use overlapped reads with timeouts, and buffer whatever number of bytes you receive, and reassemble and validate messages from multiple calls in your buffer. ... This article and associated sample code do serial communication well: ...
    (microsoft.public.vc.mfc)
  • Re: Palatable Windows IO using Ada
    ... have seen for the Win32 API simply export the ReadFile and ReadFileEx ... Windows ReadFile isn't always blocking, it can be asynchronous, see ...
    (comp.lang.ada)