-+-+-+-+-+-+-+-+ START OF PART 2 -+-+-+-+-+-+-+-+
XOriginal-From: van-bc!rsoft!agate!spool.mu.edu!sdd.hp.com!elroy.jpl.nasa.gov
V!news.claremont.edu!lucy.claremont.edu!jwilkinson@edu.Berkeley.ucbvax
XOrganization: Harvey Mudd College
XSubject: Re: Process State Detection as an Event
XMessage-Id: <1992Feb22.011527.1@lucy.claremont.edu>
XOriginal-To: info-vax@com.sri.kl
XReply-To: van-bc!rsoft!agate!spool.mu.edu!sdd.hp.com!elroy.jpl.nasa.gov!news
V.claremont.edu!lucy.claremont.edu!jwilkinson@edu.Berkeley.ucbvax
XSender:  INFOVAX-request@UK.AC.ULCC.NCDLAB
X
X
XIn article <1992Feb19.072622.288@cmkrnl.com>, jeh@cmkrnl.com writes:
X> In article <1992Feb19.013724.12701@colorado.edu>,
X>  toupine@ciaibbs.Colorado.EDU (edward toupin) writes:
X>> PROBLEM
X>>`20
X>> `09I need a way to monitor the states of some of these HIBernating
X>> `09processes to detect when they are awakened.
X>>
X>> QUESTION
X>>`20
X>> `09Is there a smart way of detecting an event (i.e. state change)
X>> `09of a process from another process other than $GETJPI?
X>`20
X> Not without some serious kernel-mode hacking.  You'd be better off finding
X> the $WAKE call in the process in question and patching in a $WAKE to your
X> monitor process. `20
X>`20
X>> `09Can an AST be useful is this case?
X>`20
X> No, ASTs (other than special kernel ASTs) are only delivered to the proces
Vs
X> that requests them.
X>`20
X>> `09Are any system flags available that can be detected to
X>> `09test for state change?
X>`20
X> For a generalized "state change", no.  Calling $WAKE sets a "wake pending"
V`20
X> bit in the Process Control Block.  However, this bit is not set for long,
V and
X> in any case you can't look at it without getting into at least executive m
Vode.
X>`20
X>> `09Is there a way to intercept the system call SYS$WAKE() when
X>> `09it is placed to another process?
X>`20
X> Again, not without some kernel-mode hacking.
X>`20
X> Look.  The reason you didn't get a satisfactory response the last time you
X> posted this was not that your request was worded poorly.  We understood wh
Vat
X> you wanted the first time.  Unfortunately, what you want isn't possible wi
Vth
X> VMS as shipped.`20
X>`20
X> I suppose you could hack RSE (Report System Event -- a part of the exec to
X> which "events" which may make processes computable are reported) to do a $
VWAKE
X> on a designated process when another designated process was made computabl
Ve.
X> However it would be moderately costly, as every trip through RSE would inv
Volve
X> a search ("is this process one that I'm monitoring?"), unless you find a
X> longword in the watched process's PCB that you could steal for the purpose
X> (risky).  Uh, don't bother searching the Grey Wall for RSE -- it's describ
Ved`20
X> in the internals manual.
X>`20
X> Perhaps this discussion will prod someone with more free time than I have
V to
X> write such an "RSE interceptor"...
X>`20
X> `09--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
X
XOne may solve the problem by using a watchpoint.  I needed something similar
V to
Xwhat the original poster wanted, so I wrote a short program to list of state
Xchanges of a given process.  I believe that state changes that happen close
Xtogether may be somewhat out of order (maybe the way I programmed it), but t
Vhis
Xstill has its uses.  One may use WP (in SYS$SYSTEM) to generate equivalent
Xinformation, although this program lends itself a little better to the probl
Vem.
X
XI don't know how reliable WPDRIVER is, so use this with caution.  This code
Xshould run on VMS V4.0 and higher, and requires PHY_IO and CMEXEC privileges
V.
XDon't forget to install the driver.
X
XJaW
X
Xjwilkinson@hmcvax.claremont.edu
X
$ CALL UNPACK [.STATE]STATE.README;1 1094194595
$ v=f$verify(v)
$ EXIT