threads and VMS [Re: dce/rpc "client" api]

[John E. Malmberg]

From: "Luke Kenneth Casson Leighton" <lkcl at samba.org>

> john, could you describe the semantics of the VMS "IO Queue" kernel-level
> API, if you are aware of it?

The documentation is online at
http://www.openvms.digital.com:8000/72final/5841/5841pro.html
The filesystem stuff is in a different manual nearby.

It is not a kernel-level API though, it is fully available and supported for
use by user programs.

It essentially is that for I/O call, including filesystem access, you have
the option of instead of waiting for the I/O to complete, you pass the
address of a routine that is executed when the I/O completes.  The I/O
itself is placed on a queue for the device.

This completion routine interrupts the execution of the main-line code, and
blocks or can be blocked by other completion routines, so you have to be
careful in coding it.  These are known as ASTs.  I remembering that as being
called an Asynchronous System Trap.

Typically for a server application you would have something like the
equivalent to "accept()" specify a routine that would look up in a state
table and schedule the next I/O with an AST as a response.  In many cases
the main line routine is in a perpetual sleep state and everything is done
by AST's.

It is sort of like building a state machine.  And you can have hundreds or
more of these routines queued up.

As I understand it, Windows NT implements a structure like this for it's
internals, but it is not exposed for the WIN32 interface.

Adding such a feature to LINUX or UNIX in a portable way would be
interesting.  My guess is that shared memory is not so much an issue as how
to use signals to trigger the correct completion routine.

Now security is another issue.  All ASTs run in the same security context as
the main process.  That is before VMS 7.2, and that is so new (about 1 year
old) that I doubt many programmers are targeting it.  There for either
security checks must manually be done, or a switch user must be done prior
to and after where user impersonation is needed.

Prior to VMS 6.x? impersonating a user required a "kernel hack".

-John
wb8tyw at qsl.network