[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