Eve: An Icon Monitor Coordinator (IPD179)

Clinton L. Jeffery
March 11, 1996

Abstract

Introduction

Some monitoring configurations

Figure 1: Monitoring a monitor; monitoring multiple TPs

On the other hand, the parental event report relationship means that if more than one EM is to monitor a TP, the TP's parent must provide other EMs with artificial copies of the TP events; MT Icon's event() function provides this service. Figure 2 depicts a parent EM that forwards TP events to an assisting EM.

Figure 2: Forwarding events to an assistant

Monitor coordinators are specialized EMs whose primary function is to forward events to other client EMs. A monitor coordinator is an event monitoring kernel that integrates and coordinates the operation of multiple stand-alone tools. By analogy to operating systems, the alternative to a kernel design would be a monolithic program execution monitor that integrates all operations into a single program.

Figure 3 depicts some relationships among MCs. Figure 3(a) is similar to Figure 2 and shows that a MC is just an execution monitor that forwards events. Figure 3(b) shows the main purpose for MCs, the execution of multiple EM's on a single TP. Figure 3(c) shows a MC monitoring a MC.

MC configurations and logic generally are limited to and revolve around parent-child relationships. For example, it is impossible to monitor events in a TP loaded and being monitored by another EM or MC unless that parent is configured to forward such events.

Figure 3: Monitor coordinators

Since event reports also transfer control, MCs also are schedulers for EMs, relinquishing the CPU to them by forwarding events to them. In the simplest case the MC forwards an event and waits for the EM to request another event before continuing; this scheduling is a form of cooperative multi-tasking. If the MC is the parent that loaded the EM in question, it can request event reports (such as clock ticks) from the EM in order to preempt its execution. Since MCs are special-purpose EMs, development of efficient MC designs falls within the scope of exploratory programming support provided by MT Icon.

Advantages and disadvantages of the MC approach

Modularity

Specialization

Extensibility

Eve, an execution monitor coordinator

Figure 4: Eve's control window

Writing EMs to run under Eve

Client environment

General-purpose artificial events

case &eventcode of {
   # ... more frequent events come first
   E_Disable: while EvGet(", 1) \sim=== E_Enable
}

Monitor communication example

while EvGet(", 1) do
   if &eventcode === E_ALoc then {
      # process requests for source code display
      }

loc := location(line, column)
event(E_ALoc, loc, &eventsource)

Eve in operation

Computation of the minimal event set

unioncset := "
every monitor := !clients do
   if monitor.enabled === E_Enable then
      unioncset ++:= monitor.mask

The event code table

every c := !monitor.mask do {
   /EventCodeTable[c] := []
   put(EventCodeTable[c], monitor)
   }

Event handling

Eve's main loop

while EvGet(unioncset) do {
   #
   # Call Eve's own handler for this event, if there is one.
   #
   (  EveHandlers[&eventcode]) ()
   #
   # Forward the event to those EM's that want it.
   #
   every monitor := !EventCodeTable[&eventcode] do
      if C := event( , , monitor.prog) then {
         if C \sim=== monitor.mask then {
            while type(C) \sim== "cset" do {
               #
               # The EM has raised a signal; pass it on, then
               # return to the client to get his next event request.
               #
               broadcast(C, monitor)
               if not (C := event( , , monitor.prog)) then {
               unschedule(monitor)
               break next
               }
            }
      if monitor.mask \sim===:= C then
         computeUnionMask()
         }
      }
   else
      unschedule(monitor)
      # if the slider is not zero, insert delay time
   }

Interactive error conversion

Figure 5: Eve's interactive error converter

An E_Error event occurs upon a run-time error. A monitor that requests E_Error events is given control before the error is resolved. Eve requests these events, presents the user with the error, and asks for an appropriate action. The code in Eve that does interactive error conversion is:

procedure eveError()
   win := open("Run-time error " || &eventvalue, "g")
   write(win, "Run-time error ", &eventvalue)
   write(win, "File ", keyword("file", Monitored), "; line ",
      keyword("line", Monitored))
   write(win, keyword("errortext", Monitored))
   writes(win, "Convert to failure? ")
   if read(win)=="y" then
      keyword("error", Monitored) := 1
   close(win)
end

Summary