ANNOUNCE - graphics package
Mon Jan 19 19:20:41 CET 2004
Vlad Dumitrescu wrote:
> From: "Luke Gorrie" <luke@REDACTED>
> One possible show-stopper that I see is handling circular message paths, which
> may lead to deadlocks.
This is unavoidable, and independent of the library design.
Here's the canonical example:
You have two input fields A and B, and they are supposed to always sum
up to 100.
Nothing easier than that: handle any event that may change A's field
value, have that event processed, then send an event to B so set its
contents to (100 - A's value).
The problem is that an event that causes B to change its contents will,
in turn, send a message to A to update that value.
There are various ways to break such a loop.
One way would be to provide a high-level "field contents has changed"
message, and have the framework check whether the contents really
changed before sending the message. (Since this example is a relatively
common situation in real GUI dialogs, this would even make sense, though
that's not a general solution.)
Another possibility is to detect the loop. If the GUI library finds that
the same set of messages is being sent between a given set of controls,
it can let them crash.
MS Windows actually does that. I once had such a message recursion, and
found that the recursion would break at level 20 or so. (That was a
mighty surprise because this behaviour was undocumented... and it
doesn't work for all messages :-((( )
In all cases, it's absolutely essential that, for every piece of code,
there's a full documentation on what messages it may send, and under
what circumstances this is done. Otherwise, programmers have a hard time
determining whether their message code is inadvertently creating a loop.
In practice, this kind of documentation is the first thing that's
incorrect. So some general guidelines are in order:
1) Divide the messages into abstraction levels. A message of a higher
abstraction level may trigger only messages at lower abstraction levels.
2) If a message must trigger another message at the same or a higher
abstraction level, this fact and the precise set of trigger conditions
must be documented. Alternatively, one could make sure that the source
code for all such triggers is easily found, either by requiring
registration in a central place (downside: all the hassles of central
registration that one would avoid), or by requiring a special (easily
greppable) form of message send (downside: works only if source code is
available - true for ex11, but not true once companies start making
Currently looking for a new job.
More information about the erlang-questions