Detecting directory changes.

[Carl Perkins]

>> So instead of blocking ASTs via a (probably never used) RMS resource, you
>> could do it on the F11B$s serialization resource
>
>That's exactly that resource that F11X$POSIX_FASTRDSEQNOS uses.
>The question is : is it really useful to re-write in C a routine that is
>already available in the system, even if it's an undocumented one ?

Since this could work on a VAX, but the routine doesn't exist there,
then it might be useful if you want it to work equally well on a VAX.

It also switches polling the lock value block using that routine every
time you want to read from the cache to something that is not polling
that resource. It is going from:

  Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of
  two things - it either enqueues a lock and dequeues the lock
  in a lock mode such that it gets a copy of the current lock value
  block, or it directly accesses the memory structures used by the
  lock manager to locate and read the lock value block. Since it is
  called "FASTRDSEQNOS" and direct access would probably be faster, I
  assume that this is what it does (probably in kernel mode).

to:

  Checking a local variable. This variable is set by the blocking AST
  to indicate that the cache is invalid. This uses blocking ASTs and
  pays no attention to the sequence number in the lock value block.

I tend to prefer notification via AST over polling. It is more efficient
and should be faster: walking the lock manager's data structures (in
kernel mode, I expect) to get the data in the lock value block and
comparing it to the saved value vs. checking a local variable to see
if it has been changed from TRUE to FALSE (or whatever) by an AST.

You do still have to worry about version compatability. I would guess
that this should at least work on any version of VMS that uses the XQP,
but maybe not.

A concern is how the other, system controlled, locks behave. If they
have possible modes that indicate read or write access, then this
should work well (e.g. they could use PR mode locks when reading and
PW or EX mode locks when writing). If they don't (e.g. they just get
set to EX mode even for a read access), then it won't work so well -
it would probably require switching to using the lock value block.
If that is the case, then it is not so usefull except maybe just using
it to get the contents of the lock value block on a VAX (assuming that
it sets this, but just not provide the F11X$POSIX_FASTRDSEQNOS routine
to read it), which "just" requries taking out the lock and converting
it back and forth between modes to get the data stored in the lock value
block every time you need it. If the VAX flavor of VMS doesn't set this
value block, then it wouldn't be useful on the VAX for that and would
probably be slower than F11X$POSIX_FASTRDSEQNOS on the Alpha (and thus
not useful there either).

So the usefullness depends on the behavior of VMS's use of these locks
and also whether or not the VAX version uses the lock value block to
store sequence number information.

--- Carl