Re: Palatable Windows IO using Ada

["Steve" <nospam_steved94@comcast.net>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:15qxrbngb2kll.wkigwit0g1tn.dlg@40tude.net...
> On 6 Apr 2006 17:21:44 -0700, Le wrote:
>
>> Wrappers we
>> have seen for the Win32 API simply export the ReadFile and ReadFileEx
>> which appear to be blocking by their very nature and demand that the
>> reader have apriori knowledge of the length of input expected at any
>> particular instance.
>
> which is true for all kinds of any I/O in any OS. You should know the size
> of the byte, block, record, line before you start to read it.
>

I disagree.

I have written a several high level drivers that communicate with serial 
devices.  In my experience, knowing the size of the byte, block, record or 
line before you start to read is the exception rather than the rule.

In my experience it is much more common to detect the end of input by the 
presence of special marker characters in the data or by the time between 
characters exceeding some threshold.

In some cases an upper limit on the number of characters that will be 
available to read is known, but not always.  In these cases multiple reads 
may be required.

> Windows ReadFile isn't always blocking, it can be asynchronous, see
> "overlapping" I/O in MSDN description of ReadFile.
>
I've been through the windows overlapped I/O for serial communications.  In 
my opinion it's a royal pain in the ass.  I think NT was the fourth OS I 
used to implement a bi-directional communications driver.  I was very 
suprised to learn that you had to do something special to have one task 
reading a serial port at the same time a second task writes to the port in 
order to make things work.  In the other systems I used, it just worked.

>> Of course one can deal with the varying length by doing all reads one
>> character at a time, but this is quite waseful in the face of Windows
>> already daunting CPU requirements.
>
> Windows does buffering in background, so it isn't that wasteful. The
> knowledge of how many items can be read at once depends solely on the
> application.
>

You're kidding... right?  Every transaction with a driver in NT involves a 
significant amount of overhead.  If you read one character at a time you're 
incurring the overhead for each character.  If you read a bunch of 
characters at once, there is just one transaction with the driver... less 
overhead.

If you have a nice library that buffers things for you, you don't have to 
worry about it.  But for serial I/O you'll have to build that on top of the 
call to ReadFile.

Steve
(The Duck)

BTW: I sent the original poster a copy of a hight level driver for XP that 
should meet their needs.

> As for serial I/O, there are further settings to keep in mind. See Windows
> API SetCommTimeouts.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de