i91@nikhefh.UUCP (Fons Rademakers) (06/25/87)
As far as I know Apollo does not have something like the
VAX AST (Asynchronous System Trap) facility. I would like to
know, however, how I could simulate something like this AST facility.
I ask this because I am making an application that has to react
to IPC events and to DIALOG events. I have a routine that sets and looks
at the eventcounts for both events and jumps to the respective
event input routines. The problem however is that the gpr (dialog)
eventcount is always increased when the locator (i.e. the mouse)
is moved, even when the mouse is outside the pad connected to the
process. This results in a lot of task_id=0 and event_id=0 events,
which makes the cursor flicker unpleasantly (because of the quick
succession of gpr_$acquire and release calls).
It would be much nicer to be able to setup an AST routine for IPC
events. This routine would then be called, a-synchronously, whenever
an IPC event occurs.
I could simulate something like AST's by sending, before sending IPC data,
a DOMAIN/IX kill(pid, SIGUSR1) signal to the remote process which then
jumps in its SIGUSR1 fault handling routine to receive the IPC data.
The problem with this scheme, however, is that I lose the ability to
send my IPC messages between different nodes, since I don't know
how to send kill's across nodes. Also I don't know how to find the PID of
a process of which I only know its name. Are there some undocumented
proc2_$... and pm_$... routines to do this?
To be short, does somebody know how to solve this problem elegantly?
Regards, Fons Rademakers.
--
Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics.
Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
UUCP: {decvax,cernvax,uck,unido,vmucnam,seismo}!mcvax!nikhefh!i91
BITNET: nikhefh!i91@mcvax.bitnet Telex: 10262 (hef nl)ganek@apollo.UUCP (06/29/87)
i91@nikhefh.UUCP (Fons Rademakers @ Nikhef-H, Amsterdam (the Netherlands).) writes: > As far as I know Apollo does not have something like the > VAX AST (Asynchronous System Trap) facility. I would like to > know, however, how I could simulate something like this AST facility. > > I ask this because I am making an application that has to react > to IPC events and to DIALOG events. I have a routine that sets and looks > at the eventcounts for both events and jumps to the respective > event input routines. The problem however is that the gpr (dialog) > eventcount is always increased when the locator (i.e. the mouse) > is moved, even when the mouse is outside the pad connected to the > process. This results in a lot of task_id=0 and event_id=0 events, > which makes the cursor flicker unpleasantly (because of the quick > succession of gpr_$acquire and release calls). I assume you're using sr9.2. In SR9.5 one of the many input improvements we made was to make the gpr eventcount a "local" eventcount. That is, a processes gpr eventcount will only be advanced when an event is enqueued to that processes gpr input event queue. (Some events are internal so you will still get an occasional(rare) spurious eventcount advance. These are primarily related to refresh events). You should see a dramatic improvement in this area if you run your application under 9.5. A note to all GRP programmers: In sr9.5 we made numerous improvements to input and cursor handling. Of course, whenever possible, we made sure that existing programs would take advantage of them - such as above. However, some improvements are not compatibile with previous releases; therefore, programs which could take advantage of them must be modified. E.g. the new gpr event gpr_$locator_update simplifies locator and cursor handling. I would recommend that all gpr programmers take time to review the sr9.5 release notes and documentaion. /dan