Re: Palatable Windows IO using Ada
- From: "Steve" <nospam_steved94@xxxxxxxxxxx>
- Date: Fri, 7 Apr 2006 19:07:35 -0700
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:15qxrbngb2kll.wkigwit0g1tn.dlg@xxxxxxxxxxxxx
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, seeI've been through the windows overlapped I/O for serial communications. In
"overlapping" I/O in MSDN description of ReadFile.
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
.
- Follow-Ups:
- Re: Palatable Windows IO using Ada
- From: Dmitry A. Kazakov
- Re: Palatable Windows IO using Ada
- References:
- Palatable Windows IO using Ada
- From: Le
- Re: Palatable Windows IO using Ada
- From: Dmitry A. Kazakov
- Palatable Windows IO using Ada
- Prev by Date: Re: Palatable Windows IO using Ada
- Next by Date: Re: Palatable Windows IO using Ada
- Previous by thread: Re: Palatable Windows IO using Ada
- Next by thread: Re: Palatable Windows IO using Ada
- Index(es):
Relevant Pages
|
