ANNOUNCE - graphics package

[Peter-Henry Mander]

Hmm, I don't like the idea of using garbage collection to clean up X-Window resources; The widgets would stay on the screen, leaving unresponsive zombie windows on the screen, until a (non-deterministic?) GC occurs. That leaves a bad impression on the user (i.e. me!)

Lets leave GC alone, it was designed for a single purpose, and I hate piggy-back features stapled on because the problem wasn't analysed thouroughly enough to come up with the right answer!

To summerise, I can imagine two scenarii:-

  A) Process controlling widget terminates --> delete corresponding X-Window widget.

  B) User kills X-Window widget --> controlling process gets a `close' message (or dies).

Maybe there ought to be _two_ linked processes for each widget, or at least a supervising process that monitors the X connection and the corresponding Erlang process(es). If either disconnects/dies the other is likewise terminated.

Would this be a reasonable mechanism?

Pete.

On Wed, 21 Jan 2004 11:33:19 +0200 (EET)
Taavi Talvik <taavi@REDACTED> wrote:

> On Tue, 20 Jan 2004, Peter-Henry Mander wrote:
> 
> > Sounds like two distinct problems, please explain why they're the same
> > (if they are).
> 
> > I think Joe's problem is to maintain consistency between what is visible
> > on screen, and what the Erlang data structures contain, i.e. the user
> > kills a window (maybe forcefully) but ex11 isn't aware the window has
> > gone. The windows don't unexpectedly vanish (I hope!)
> 
> > Am I correct Joe? I would expect some form of event or notification in
> > this context. My knowledge of X11 is not all that good, so I'm probably
> > babbling.
> 
> > The erlang-gtk thing sounds like a garbage collection issue, i.e. how to
> > keep window handles within the reachable memory set. If the window
> > reference is no longer reachable, it get garbage collected and probably
> > destroyed.
> 
> I beleive, that this is similiar problem.
> 
> Joe greates some widget - erlang process. This erlang process fires
> some commands to X serverver via sockets. X server allocates some
> resources on behalf of Joe's widget.
> 
> When Joe's widget is not needed anymore, it can be explicitly
> deleted. And widget process fires again some commands to X server
> to deallocate resources on X server side.
> 
> 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.
> 
> best regards,
> taavi
> 
> 


-- 
"The Tao of Programming
 flows far away 
 and returns 
 on the wind of morning."