Detecting directory changes.

[Carl Perkins]

>> Doing whatever F11X$POSIX_FASTRDSEQNOS does. This is one of
>>  two things - it either enqueues a lock and dequeues the lock
>>  (...) , or it directly accesses the memory structures used by the
>>  lock manager
>
>The routine actually enqueues/dequeues a lock, and does not access directly
>the lock manager data structures. That's true is not so "FAST", but I assume
>it does this because it does not want too be too much dependant of the
>internal data structures, which are regularly changing when VMS version
>changes.

Interesting. In that case, it is probably not actually any faster than doing
it yourself.

>> I tend to prefer notification via AST over polling. It is more efficient
>> and should be faster
>
>I do too, but may be not in this case, because 
>1. doing this may interfer with internal VMS behaviour, and slow down the
>entire system (imagine you have a big lot of SMBD processes), 

I can't immagine that this would be much of a problem. You would have
"a few" more locks in existance at any time is all. The tradeoff would be
a little more memory for the lock manager and possibly slightly longer
lists in the hash nodes that take a little more time to check for the
lock manager, when it hits the slightly more frequent nodes with more
than one entry.

>2. you may end with a huge number of locks (one per directory/per SMBD
>process)

How many different directories does you code maintain a cache for at
a time for one process? It seems to me that it should maintain only a
few - the most recently accessed directory and some number of previous
directories, where "some number" could be a fixed value, controllable
via the SAMBA.CONF file or a logical name, or might depend on how much
memory each is using (i.e. you could limit it by memory use instead of
by a specific number of directories). As I recall, Windows looks into
each subdirectory when a directory is first accessed just looking for
desktop.ini files, I think - I don't recall it wanting a full directory
listing of each. Are individual files cached? Are the directories that
a file is in cached when a specific file is looked for, or only for
full directory listings? (Yeah, I know - I could look at the source,
which would answer all of these questions.)

I don't think the number of locks is likely to be a problem. Even on a
small and fairly lightly used system there are usually thousands of locks.
With 1000 SMBD processes each caching up to a maximum of 100 directories
it might be a problem (which should be solved, mostly, from a simple
autogen to adjust the relevant parameters to account for the additional
lock usage). With 10 SMBD processes each caching up to 10 directories
it wouldn't be a problem.

>3. using blocking ASTs in kernel mode can be highly dangerous, because image
>exit does NOT dequeue those locks, so you must be absolutely sure that there
>is no kernel blocking AST left when you exit, unless you'll crash when
>trying to execute a blocking AST routine that is no more in memory.

This is a concern. The code that does this should be absolutely clean
and there should be an exit handler that knows how to clean the process'
locks up.

This is probably the strongest argument against doing it. Whether or not
it is strong enough to stop you from doing it is another question.

>> (about rewriting the F11X$ routine in C)
>> 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.
>
>That's true, and would make it a little less undocumented/unsupported,
>because it would only depend on the resource names used by the XQP, and not
>on the actual presence of the F11X$ routine. I'll do it as soon as I have a
>little time.

Just be carefull. 

--- Carl Perkins
    Computer Systems Manager
    Geochemical & Environmental Research Group
    Texas A&M University
    carl at gerg.tamu.edu