ANNOUNCE - graphics package
Wed Jan 21 11:30:15 CET 2004
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?
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
> Pid ! Message
> Then process can take whatever actions necessary to free
> external resources associated with this reference.
> best regards,
"The Tao of Programming
flows far away
on the wind of morning."
More information about the erlang-questions