[Info-vax] DCL "READ/TIME_OUT=n" from terminal; timer resets if message written to screen
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Sat May 22 19:37:07 EDT 2021
On 2021-05-22 15:18:02 +0000, Robert A. Brooks said:
> On 5/22/2021 11:11 AM, Scott Snadow wrote:
>
>> VSI, if you're reading this, a documentation enhancement request:
>> Please mention this in the DCL Manual and also in "HELP READ /TIME_OUT"
>> since a casual DCL programmer probably wouldn't be perusing the I/O
>> User's Reference Manual very often!
>
> Noted.
>
> I'll pass it along to the doc team.
Referring to the current behavior as "documented" as per a previous
posting here is, well, generous, and calling this behavior appropriate
yet more generous.
Who here thinks that a broadcast should reset an input timeout timer?
Principle of least surprise and all.
At least with a $qio or $io_perform and a timeout, I can (mostly) avoid
that get-interrupted-and-the-timer-resets mess.
BTW, one of the safer approaches for dealing with this within an app is
to first set an "ignore" flag (interlocked bitlock) somewhere and
either let the $qio or $io_perform AST fire, or set the flag and issue
a $cancel.
OpenVMS lacks means to fire off a thread save via an AST, and the
queuing is necessarily home-grown within the app. But I digress. For
those that haven't looked into it and are working with asynchronous
processing (on other platforms), FRP can get interesting here, too.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list