shap@sequent.UUCP (Shap Shapiro) (03/03/90)
> Date: Thu, 01 Mar 90 16:36:12 -0500 > From: rws@expo.lcs.mit.edu (Bob Scheifler) > > For applications that use a single application context and want to exit > immediately upon its destruction, I can accept that the overhead of all > those "unnecessary" calls to free should be avoided. Perhaps that means > there should be an XtPrepareToDie that simply invokes the destroy callbacks > of all widgets, but doesn't free memory or X resources. > > The destroy callback currently (I think) has an unused call_data argument. > Suppose we place an interpretation on this, to distinguish between: > > 1) "normal" widget destruction, in which cleaning up of all state should be > performed: malloc'd memory, X resources, and otherwise permanent objects. > > 2) "close" destruction, in which cleaning up of X resources is not required, > since the X connection is being closed. > > 3) "exit" destruction, in which cleanup up of X resources and malloc'd memory > is not required, since the program will immediately exit. > > The only penalty for ignoring this new data is speed-of-termination, I think. > The advantage is that applications would be better insulated from widget details. I personally feel that it is a good design practice for objects (widgets, applications, whatever) to clean up after themselves when they go away. I can also relate to concerns about performance, especially for an application that might be manipulating many widgets. Another approach would be to add the ability for a widget to register the fact that it MUST be notified before the program exits. The XtPrepareToDie could then have an option to only call those widgets that MUST be notified, and leave it up to the application to decide how much clean-up is desired before an exit. Shap ------------------------------- Shap Shapiro Sequent Computer Systems 15450 SW Koll Parkway Beaverton, OR 97006 (503) 626-5700 {uunet|ogicse|tektronix}!sequent!shap sequent!shap@cse.ogi.edu -or- shap@sequent.UUCP