ANNOUNCE ex11 release two

[Joe Armstrong]

On Thu, 22 Jan 2004, Vlad Dumitrescu wrote:

> From: "Joe Armstrong" <joe@REDACTED>
> > 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
clearer.

  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
process.

  If the exit reason is not  "normal" then it prints a "helpful" error
message.

  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.



> 
> /Vlad
>