[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