27 Feb 95, Mark Kimes writes to Jon Guthrie:

 >> The control you get using the DCB is inadequate for my purposes.

 > 10th of a second timing is unsatisfactory, so you'd prefer an "API"
 > that's actually got 10th second timing but acts like it's not?  :-)
 > Even your "secondary thread" method is limited by the available
 > APIs, you know.

If you would stop jumping to conclusions (first that I didn't know about
IOCtl C1F53, then that it was some cockamamie notion about precise timing
in a comm program) and ask me WHY it's unsatisfactory, you might have an
easier time of it.  The "10th second resolution" isn't the issue.

Fact is, my response has been delayed while I attempted to figure out WHY I
switched from the solution that you recommend to the one that I used.  All
I could remember at the beginning was that I had a good reason to switch
and that my reasons had something to do with timing.  (I found the
arguments that you used to support your position the last time the subject
came up to be quite
compelling.)

As I recall, the last time I implemented a second thread, I was writing a
library so that I can produce door programs.  Among other effects, I wanted
to be able to allow the user to type in escape sequences (like the ^[[A
that most terminal programs transmit when you hit the up-arrow key) and
still recognize single escape characters.  The ONLY way of doing this
reasonably is to use an inter-character timeout.  It is NOT possible to do
a proper inter-character timeout without a second thread because the
timeout time is set for a single call to DosRead() but the total elapsed
time is from the end of one DosRead() to the end of the next DosRead(). 
The difference is the time spent running the program between calls to
DosRead() which, if you don't spawn a new thread, you have no effective
control over.

Once the characters are together in the serial driver's buffer, all timing
information is lost and you can't tell whether what really happened is
"^[[A"
or "^[[A".  The former is interpreted as a single
"up" sequence, the second is interpreted as three separate
characters.  You need to gather that sort of information BEFORE the
characters are buffered.  Gathering that timing information and storing it
for future use is the essential difference between
getting the serial driver and my serial read thread.

My "doorio_getchar()" routine returns the character received or a
code which means "up one" or "down one."  Doing it
without the additional receive thread would cause what I believe to be an
unnecessary and inconvenient combining of two levels of code, the one
receiving the data and the one interpreting the incoming data stream.  With
the "extra" thread I don't even have to document what's going on,
let alone require that calls to "doorio_getchar()" be no more
than 250 ms apart, which is what I believe your method requires.

If you can come up with a scheme that will do what I need to do (which
includes, but isn't limited to, this escape-sequence recognition) then I
will happily abandon the overhead of the additional thread, but it does
seem necessary to get what I want.

- Jon

--- GoldED/2 2.42.G0214