ANNOUNCE - graphics package

[Vlad Dumitrescu]

----- Original Message ----- 
From: "Taavi Talvik" <taavi@REDACTED>
> It would be nice if this deallocation of external resources is transparent
> - i.e. if widget process just terminates (by crashing, or just finishing
> it's work without cleaning up resources), some time garbage collection
> kicks in and garbage collector informs somehow, that external resources
> can also be freed.
>
> Not knowing anything about erlang VM internals, following may be useful
> for tracking external resources tied to erlang variables.
>
> Create new type with
>
> make_external_ref(Pid, Message)
>
> whict behaves like current make_ref/0. However, when this
> reference is to be garbage collected following message is
> sent
>
> Pid ! Message
>
> Then process can take whatever actions necessary to free
> external resources associated with this reference.

A problem with such a scheme is that one has no control over _when_ the
collection will take place. This may be important.

Another problem is that today in the normal heap management (one hep per
process) when the process dies, the heap is just discarded as a whole. If it
were to be scanned for dangling references, the lightness of the processes would
be affected negatively (I think).

I am not sure about this, but external references might also affect the
generational property of the memory manager.

Also, what if the associated Pid is dead?

In short, it would need quite a lot of changes to implement it at the language
level. I think a good analysis is needed, to show if it would be worth it or
not.

There are other solutions: using supervision trees can get you a long way, and
if it's not enough maybe a registry of external resources can be used (workers
register callbacks to be used when they die).

regards,
/Vlad