ANNOUNCE ex11 release two
Thu Jan 22 15:11:22 CET 2004
On Thu, 22 Jan 2004, Vlad Dumitrescu wrote:
> From: "Joe Armstrong" <>
> > On the contrary I think this is *exactly* how it should be done.
> I can see your point, it's more flexible, even if it's more to write :-).
Yes - the widget code is about twice the size of the code in the
previous release (that is the code per widget) - But it is a lot
I had to make a load of design decisions, so I decided that all
widgets are linked to the driver. If the driver gets a process EXIT
signal it just kills the entire tree of windows which are owned by the
If the exit reason is not "normal" then it prints a "helpful" error
The driver *interprets* exit signals as meaning that all windows
owned by the processes should be destroyed - this is why the top level
program must go into an infinite loop. I need some way to tell the
driver that the application has terminated.
Basically if you can see something on the screen (a top level
window) or a widget in a window - then there must be a process which
controls it. If the process dies the windows are removed and and
most resources reclaimed (not yet ... :-)
> The possibility to (accidentally) sending a callback that does a lot of
> computations remains, and the widget (not the Ui, you're right) becomes
> unresponsive then.
> What about crashes in the callbacks? Is it enough to wrap them in a catch?
I view things like this - if the callbacks result in "exit non
normal" then the code is screwed and it is pointless to continue, so I
crash the entire application. If exit(normal) occurs in a widget, the
widget will just vanish. test1.erl demonstrates this.
Basically, users must write their calls backs so they do not damage
the widgets - if the callback causes an exit(normal) the widget is removed.
exit(nonNormal) removes the widget *and the entire application*.
If you spawn_link the *entire* application and trap exits you can trap this
and do some recovery.
This seems to be the best compromise - remove the widget but let the
application continue for small errors in the callbacks. Zap everything
for serious errors.
More information about the erlang-questions