[Info-vax] yet another sys$qiow question

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sat Aug 22 10:20:46 EDT 2015


On Saturday, August 22, 2015 at 12:29:06 AM UTC-4, JF Mezei wrote:

> From a programmer's point of view, if I were to test for strlen(buffer) != 0

Accessing an in-transition data structure with a known-unsafe, 
data-dependent and should-be-deprecated C call?  That never ends well.

Expunge all of the str not-l, not-r variants from current C code being 
reworked, and from new C code.

But I digress...

As for the issue that JF posits, VMS hasn't particularly called out the 
concept of object "ownership" in most of its programming contexts, 
unfortunately.   It's most definitely present, but it's not as overt as 
it could or should be, and there's a whole lot of sharing going on 
between the system and the application program.

The concept of object ownership came to the fore with APIs and with 
buffers implemented as objects, and particularly also with garbage 
collection; with newer programming interfaces and newer approaches.

The whole IOSB discussion — both in terms of the 
entirely-compiler-specific volatile declaration, and in terms of the 
potential for stack allocation and lifetime — can be abstracted 
differently; into objects and object lifetimes.  The compiler and the 
run-time can then automatically maintain what's variously called object 
reference counting for the programmer, and the programmer can rather 
more explicitly account for the various data structures.   In OpenVMS 
terms, most data structures (objects) are allocated from the heap and 
not from the stack, and are automatically deallocated when the data 
structures (objects) go out of scope.

Ownership and access and release are central to more than a few parts 
of OpenVMS interface confusion — of when you can access stuff, and when 
the data structures can be released.    In this case, you don't want 
the IOSB storage released until the application code is done with it, 
and the programmer's routines don't "own" the I/O buffer until it's 
been returned by the system routines.  Even easier, just have the call 
trigger some of the application code and have that code handed a 
structure akin to the IOSB.  With this, the whole mess disappears — the 
compiler doesn't have to be told about the out-of-scope asynchronous 
access, there's no volatile, etc.

Alas, the OpenVMS APIs predate this whole approach, though.



-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list