🚀 go-pugleaf

> > 
> >     Every UN*X system that I've used allows the programmer to create a
> >     file, and then unlink it from the file system.
> > 
> > This doesn't help for files that you *want* to stay around in the
> > event of a crash.

> Very good Bob, but according to my source, Mr. Blow *wanted* a TEMP 
> file.  It was the fact that an *unwanted* file was left after a crash
> that started this whole thing.  Had Mr. Blow been finding his widget to
> be leaving behind mega-bytes of useful data I'm sure that he would have
> never complained about file space consumption.  Your comment seems a 
> bit out of context.

Bob's message is an attempt to help people understand the more general
problem.  A problem that may be a design flaw in the Toolkit.  I will try 
to state the general problem the we seem to have uncovered by thinging about
how to solve the specific problem of the user.

Problem:

It is very difficult for an application writer to shutdown an Xt client cleanly.
If she makes the assumption suggested by the originaly poster then widgets are
the only ones who have enough information to clean up all their resources.  The
programmer must be sure that all widgets get destroyed before the application
exits.  The current Xt specification is unclear about whether or not this
happens automatically when your call XtCloseDisplay, and
XtDestroyApplicationContext.

Paul has proposed that there is insuffecient mechanism in the toolkit to
effeciently clean up these resources since there are really three types of
widget resources:

1) Those that must always be cleaned up by the widget.

2) Those that will automatically be cleaned up by the operating system when
   the program exits.

3) Those that will be automatically cleaned up by the X Server when the display
   connection is closed, or the program exits.

It seems that for optimal performance there are really three different kinds of
widget cleanup that may occure.

Solution:

We have begun internal Consortium discussion on this topic, and will attempt to
come up with a solution, but since this discussion is very preliminary I do not
want to comment further in this public forum.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213