From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9bdd666589befb0f X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 07 Apr 2006 21:06:12 -0500 From: "Steve" Newsgroups: comp.lang.ada References: <1144369304.698267.277640@u72g2000cwu.googlegroups.com> <15qxrbngb2kll.wkigwit0g1tn.dlg@40tude.net> Subject: Re: Palatable Windows IO using Ada Date: Fri, 7 Apr 2006 19:07:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Message-ID: NNTP-Posting-Host: 24.20.111.245 X-Trace: sv3-ATB0FYTV5bCq5AxF+F78Ljw1D5Y9eEMsFdOftOlkB+Yp0b6wGeXP2gQ9YDMnZHfQCOEpeS7GUJ2vWS8!fDOb4lJDyQS3JsS+6RQ6Yx3EwQvku2BUx2YTR+B4ccT3NuBofR6Cg/wgkdhy/FLqBsZS7kVeYSGz X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:3755 Date: 2006-04-07T19:07:35-07:00 List-Id: "Dmitry A. Kazakov" 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