ANNOUNCE - graphics package

Taavi Talvik taavi@REDACTED
Wed Jan 21 10:33:19 CET 2004


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




More information about the erlang-questions mailing list