[Info-vax] yet another sys$qiow question

[Stephen Hoffman]

On 2015-08-21 16:26:04 +0000, Craig A. Berry said:

> ...it also says it's not the preferred method and recommends using 
> SYS$SYNCH instead. So it would also be a fair reading of the manual to 
> say it recommends against the polling method even though it includes an 
> example of it. I wish it would say "don't do that" a bit more strongly.

Waffle-wording these changes is a longstanding tradition for OpenVMS; 
recommendations that don't have any requirements.

Forever-upward-compatibility is theoretically quite wonderful, but 
empirically rather more of a disaster, as the old cruft and the costs 
and the code complexity inevitably accrete.   For those few cases where 
incompatible changes are required and for whatever reason, I'd prefer 
to see engineering provide the improvements and a documented migration 
path for existing code, announce the deprecation schedule, nuke and 
remove the old APIs as appropriate, and move on.

But then — and with no small amount of irony — the deprecated-features 
manual was itself deprecated.

> The only thing the discussion of volatile has added is yet another 
> reason not to do it that way.

Unfortunately and AFAICT, omitting volatile for any of the completion 
paths means that any of the IOSB paths can potentially pick up a bogus 
value.  That seems very unlikely, but it is permissible behavior for 
the compilers.  Ways out: use of volatile either by the user or via the 
system-provided declarations, language extensions for the IOSB, or 
gonzo-grade compiler heuristics.  Only the lattermost avoids source 
changes.  Or notice from VSI that the classic $synch approaches works, 
and that the compiler does "the right thing" for the IOSB, where all of 
this adventure disappears in a puff of greasy orange moot.


-- 
Pure Personal Opinion | HoffmanLabs LLC