mouse@LARRY.MCRCIM.MCGILL.EDU (11/05/90)
> I have a (graphics) program written using one of the widget sets. My > understanding is that when resources such as windows and GCs are > created, they are stored "in" the server and accessed through their; > ids. This is true. The client-side libraries will usually keep a shadow copy of much of the state of any GCs created, but this does not affect this discussion either way. > My question is: should my program explicitly destroy these resources > upon termination? Yes and no. The "no" answer is perhaps easier to explain first: no, you don't need to explicitly destroy them; indeed, unless you have taken explicit steps to the contrary (XSetCloseDownMode or some Xt or widget-set analog thereof), they will be destroyed automatically when your connection to the X server drops upon exit. The "yes" answer: this answer comes out of a software design point of view; it's based on the principle that every module should clean up after itself, because it makes it much easier when someone wants to use that module as a part of something larger. How compelling this argument is in your situation I cannot decide for you. I suppose I can summarize as "Yes you should but no you don't need to". > It appears that the server's size grows and stays that way after my > program terminates. Is this normal or consequence of not freeing up > the resources? If the server is running on anything even vaguely like a normal UNIX system, this is normal: the server has freed the space for re-use in the malloc/free sense, but the malloc package does not release freed space back to the operating system, so the OS never sees the process shrink. To test this, run the program again, and (I trust) discover that the server does not grow any further, because the server simply reuses the space that it didn't give back to the OS. I understand that there exist malloc packages that are smart enough to release freed space to the OS, but they are not terribly widespread and often can't release the space anyway because of the conditions the OS imposes on such releasing. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu