Re: Palatable Windows IO using Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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

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