STEINBERGER@SRI-KL.ARPA (Richard Steinberger) (03/20/87)
I have been using f$getjpi(PID,"ASTLM") to continuously monitor the number of
remaining ASTs in my quota. (The parameter may not be ASTLM - I'm not using
the machine that the code runs on now - But it does give the remaining ASTs
correctly). That is, I run a program on one terminal and use the f$getjpi
call (in a loop) to keep track of the AST count (displayed).
When the count decreases it means (I believe) that another AST has been
queued. When the count of remaining ASTs increases it means that an AST
was just delivered to the monitored process.
Is there a way to ascertain what hardware device actually delivered the AST?
Can additional information be found? I know the exact MACRO instruction (in
the application code) that results in the remaining AST count being
incremented by 1 (it happens to be a CHMK instruction in SYS$DASSGN).
Where is the (software) information about what ASTs are queued stored and how
is it accessed? When you're 'sitting' at the DCL prompt, usually 2 (or is
it 3?) ASTs are queued. I assume these are for CONTROL-T, CONTROL-Y and/or
CONTROL-C or user TTY input. I would like to be able to know what ASTs
are queued (i.e. from what devices and what AST routines would be called)
at any given moment.
Thanks to all who reply.
Regards,
Ric Steinberger
steinberger@kl.sri.com
(415) 859 - 4300
-------LEICHTER-JERRY@YALE.ARPA.UUCP (03/21/87)
I have been using f$getjpi(PID,"ASTLM") to continuously monitor the number
of remaining ASTs in my quota.... That is, I run a program on one terminal
and use the f$getjpi call (in a loop) to keep track of the AST count
(displayed). When the count decreases it means (I believe) that another
AST has been queued.
NO! There are three events in the life of an AST: Creating the request for
an AST (for example, doing a QIO and providing an AST address); having the AST
queued; and having the AST delivered. You are charged for the AST at the time
you enter the request for it; the VMS design assumes that, when it comes time
to queue an AST to you, that can be done immediately with no additional check-
ing of quotas. (In fact, the space needed to describe the AST is allocated
at that time, too; actually queueing an AST to a process is a very quick
operation.)
When the count of remaining ASTs increases it means
that an AST was just delivered to the monitored process. Is there a way
to ascertain what hardware device actually delivered the AST? Can
additional information be found?
There are queues of pending AST's starting in the process header somewhere;
check the Internals book. It would take some hacking, but you could read out
the address at which the AST will be delivered and the AST parameter that
will be passed. There is no indication of what device caused the AST; you'll
have to determine that yourself. (Note: For AST's that result from I/O
completion, the AST block - the name of which escapes me - is actually a
re-used IRP. The IRP contained all the information needed by the driver to
do the I/O. However, some of it is over-written when the IRP is turned into
an AST block.)
That said, you are unlikely to catch an AST on the queues with the approach
you are pursuing. GETJPI gets information about another process by queueing
a special kernel-mode AST to it to run code that gets the information, then
returns it with another KAST. With all the context switching and rescheduling
and such, by the time you notice that the other process got an AST, chances
are it's at least been delivered, and probably processed and dismissed.
I know the exact MACRO instruction (in
the application code) that results in the remaining AST count being
incremented by 1 (it happens to be a CHMK instruction in SYS$DASSGN).
Where is the (software) information about what ASTs are queued stored and
how is it accessed? When you're 'sitting' at the DCL prompt, usually 2
(or is it 3?) ASTs are queued. I assume these are for CONTROL-T,
CONTROL-Y and/or CONTROL-C or user TTY input. I would like to be able to
know what ASTs are queued (i.e. from what devices and what AST routines
would be called) at any given moment.
Now you're asking a rather different question. AST requests associated with
devices are stored in several different places. AST's that get delivered on
QIO completion are in the IRP that describes the I/O request; IRP's, in turn,
are in a queue that starts in the UCB. Attention AST's are also in queues
that start at the UCB; they have no associated IRP. Some devices have
multiple AST queues - it's all up to the driver.
There is no simple answer to your questions, and it isn't really clear what
you are trying to accomplish. In general, though, trying to get this sort
of low-level information will require rather delicate kernel-mode hacking.
-- Jerry
-------