Re: Palatable Windows IO using Ada

On Fri, 7 Apr 2006 19:07:35 -0700, Steve wrote:

"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 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.

This is a higher level protocol. The point is that when the OS does not
natively support a device-specific application layer protocol, and it
normally does not, then there is no other place to do it as in the
application. So the communication item becomes one byte. Blocking for more
than one byte at once is looking for troubles. Even if the protocol has
things like bytes counts. Practically none of multiple serial devices we
dealt with worked according to the specification. Using bytes stream full
duplex communication model has saved us a lot of time, because we could
easily adapt our software and overcome bugs in the hardware.

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.

Yes. In my opinion it is overkill to use overlapped I/O for serial
connections. Though if you have 1000 devices to handle simultaneously,
there might be no other choice. In RSX and VAX, where the idea of
asynchronous I/O seems was borrowed from, it worked well. I also think that
overlapped I/O and asynchronous system trap could nicely fit to Ada's
protected objects. The interface to overlapped I/O is so clumsy because API
is in C, it should be in Ada! (:-))

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.

I didn't saw any significant difference when using synchronous vs.
asynchronous read for serial devices. Taking into account serial connection
speed I doubt one could notice it. A more interesting case is socket I/O.
Our commercial software reads from sockets using 1 byte buffer and blocking
read. Recently we did elaborated time measurements under Windows XP and
Server 2003 for stream uni- and multicast sockets. It was all but easy,
because of quite flawed design of Windows time services. But that's a
different story. Anyway, our experiments have shown that the bottleneck
wasn't communication. We tested publisher / subscriber services of our
product and have noticed that the communication layer by margin outperforms
other (local) parts. Roughly, global mutexes and context switches are much
worse than I/O APIs, even if the former are used per data block and the
later per byte.

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.

There is no other choice. The transport layer of serial connection is byte
stream. It is a medical fact. (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Palatable Windows IO using Ada
    ... This is a higher level protocol. ... So the communication item becomes one byte. ... In my opinion it is overkill to use overlapped I/O for serial ... overlapped I/O and asynchronous system trap could nicely fit to Ada's ...
    (comp.lang.ada)
  • Re: Pure speed
    ... Basically this LISP program ... Is there some way to make a bigger buffer for I/O? ... the speed hit may occur at the character decoding stage. ... > 256 1-1 byte to character encoding, we can get fast enough test I/O if ...
    (comp.lang.lisp)
  • Re: NEW_LINE()
    ... character data on it, what I really want (and what I thought stream ... I/O was going to give me) was the ability to do formatted I/O ... looks like a implementation-dependent record mark will be converted ... I can do unformatted stream I/O with CHARACTER ...
    (comp.lang.fortran)
  • Re: WriteFile()
    ... whether the I/O is synchronous or asynchronous doesn't change anything. ... With a direct-access storage device file, one can expect that WriteFile ... Again, when a timeout concept is NOT part of the design, a BLOCK call can ... let's apply your argument to ReadFile. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [OT] Re: How does C work on non-unix?
    ... So I can't debate that C makes sense on Unix; ... Pascal and Ada do text I/O as character streams broken into ...
    (comp.lang.c)