kernel question - VMS

This is a discussion on kernel question - VMS ; Maybe someone who knows the kernel better than I can explain this one. I've been wondering about it for years. It's my understanding that $GETJPI posts an AST to the target process to get information. I assume that it doesn't ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: kernel question

  1. kernel question



    Maybe someone who knows the kernel better than I can explain this one.
    I've been wondering about it for years.

    It's my understanding that $GETJPI posts an AST to the target
    process to get information. I assume that it doesn't do anything
    special if the target process happens to be the current process.

    If so, then when the target process is the current process how is
    it that the current process can run user mode code in the main
    thread prior to return of the requested data? I thought the scheduler
    would honor the request for the AST in the current process and then the
    kernel would copy the data to the user's buffer before returning to user
    mode. Doesn't the AST code pre-empt the main thread? Or is there a
    delay somehow between AST completion and return to the kernel to copy
    out the data?

    I've seen this happen since VMS 3.0, where that results in the
    returned data being blank until an appropriate wait is done for
    the selected event flag. We updated from VMS 2.5 and saw this
    in a program where the programmer put in a comment that he didn't
    care about the warning that $GETJPI would become asynchronous because
    the main thread wouldn't get to execute anyhow. But it did execute
    and choked on seeing zeros where the data was to be returned. The
    fix, of course, was to use the then new $GETJPIW and curse the
    programmer for thinking he new better than DEC on how VMS would
    work in his future.

    But I've never seen anything in the internals manual or when reading
    the fiche that helped me understand the mechanism by which this
    happens.


  2. Re: kernel question

    Looking at the listings it appears that getting data from the current
    process is dealt as a special case. I have not read all of it to see
    if it it possible for this to be asynchronous rather that just copying
    the data from the relevant data structure (which I expect is
    synchronous).



  3. Re: kernel question

    further reading indicates that for some items (e.g rights lists) or
    under certain conditions the special kernel AST mechanism is always
    used even for the current process.


  4. Re: kernel question

    In article <1188484215.394805.167460@r29g2000hsg.googlegroups. com>, IanMiller writes:
    > Looking at the listings it appears that getting data from the current
    > process is dealt as a special case. I have not read all of it to see
    > if it it possible for this to be asynchronous rather that just copying
    > the data from the relevant data structure (which I expect is
    > synchronous).


    Curiouser and curiouser. Thanks for taking the time.



  5. Re: kernel question

    In article <1188484771.067327.27590@19g2000hsx.googlegroups.co m>, IanMiller writes:
    > further reading indicates that for some items (e.g rights lists) or
    > under certain conditions the special kernel AST mechanism is always
    > used even for the current process.


    I don't recall what the code was looking for, possibly the username,
    but since the rightslist didn't exist in VMS 2 when the code was
    written I'm fairly sure it wasn't intended to look there.

    On the other hand, if it was looking for the UIC I supposed the
    rightslist might be consulted for the corresponding string even
    if the binary UIC was wanted.


  6. Re: kernel question

    On Aug 30, 9:38 am, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:

    > It's my understanding that $GETJPI posts an AST
    > to the target process to get information.


    This is true for *some* items. Bear in mind that what the
    general user thinks of as "process information" is kept in
    no less than four different structures (PCB, PHD, JIB, CTL).
    My code (which looks at each process every few minutes)
    separates the JPI items into four different categories:
    "frozen" (data which never changes)
    "cold" (data which seldom changes)
    "warm" (unable to obtain if process is outswapped)
    "hot" (relatively cheap to obtain)
    to prevent the AST you mention from being triggered unless
    one or more of those items is actually needed.

    > I assume that it doesn't do anything
    > special if the target process happens to be the current process.
    > If so, then when the target process is the current process how is
    > it that the current process can run user mode code in the main
    > thread prior to return of the requested data? I thought the scheduler
    > would honor the request for the AST in the current process and then the
    > kernel would copy the data to the user's buffer before returning to user
    > mode. Doesn't the AST code pre-empt the main thread? Or is there a
    > delay somehow between AST completion and return to the kernel to copy
    > out the data?


    Gah. I used to know this. I'll look through my notes
    when I get home, and post if I find anything useful.

    ok
    dpm


+ Reply to Thread