Feb2001 hugs98 on MacOS
Hans Aberg
haberg@matematik.su.se
Sat, 3 Mar 2001 15:31:56 +0100
At 15:35 -0700 2001/02/28, Alastair Reid wrote:
>I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of
>these approaches (i.e., without requiring substantial internal changes to
>Hugs).
In view of that the high-level AppleEvent events are interrupts, one ends
up the same kind of problem of atomizity (code which cannot be interrupted
by other threads) as in a pre-emptive environment.
Here are some problems:
1) If the Hugs code is sloppily written, this can cause problems. For
example, Hugs uses its own stack, so if it first writes the stack and then
increases the stack pointer, this would cause a problem if the interrupt
occurs between the write & the pointer increment. Similar problems can
occur if a variable is temporarily used for something else than its
intended use. For example, the console package that came with the Mac CW
compiler uses the cursor position for something else while reading a
character, which means that if an interrupt happens then, the cursor
position value becomes wrong.
2) Some operations may not allow the Hugs engine to compute at all, say a
GC cleanup.
3) If Hugs code is impure, that is, using global temporary registers (as I
think it does), this is a problem if the interrupt happens in the middle of
the execution of an impure function.
The remedy for 1), is to rewrite the code so that it becomes semantically
correct (disregarding simplifications that might work in a single-threaded
environment). And as for 3), it is best to rewrite the code so that it
becomes pure.
However, there is an interesting way in which the Hugs kernel might be made
to simulate simple form of concurrency, even though the kernel is not
written for it:
When an interrupt happens, the function that is handling it is allowed to
register a function pointer in a queue, whereafter it terminates. Then the
Hugs kernel sources are sprayed (just as in the case of cooperative
multi-tasking) with places where the function pointers in this queue (if
non-empty) can be executed.
It should be relatively simple to implement: One only needs to identify
some places in the code where it is admissible to execute those function
pointers. (One exception is when the Hugs kernel is idle, in which those
function pointers should be executed immediately and not enqueued.)
That is, if one want to allow a high-level event to be treated by the Hugs
kernel while the Hugs kernel is actively running.
Hans Aberg