From: Ragnar Hojland Espinosa [mailto:ragnar@linalco.com] I want to automatically call self terminate on an object on destruction (or when it goes out of scope..)
Smalltalk objects are not 'destroyed'. They are garbage-collected at some time after no other object references them. The 'some time after' could be microseconds or days.
I can't find out how to write a destructor or something functionally equivalent.
Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object.
- Peter
On Tue, Oct 22, 2002 at 03:55:39PM +0100, Peter Crowther wrote:
I can't find out how to write a destructor or something functionally equivalent.
Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object.
Finalize did get some nice matches. Does finalize get called right away, or only when squeak does the GC? And if so, am I guaranteed that it'll be GCed that moment?
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I can think of.. so I must be missing something.
On Tue, Oct 22, 2002 at 06:11:41PM +0200, Ragnar Hojland Espinosa wrote:
On Tue, Oct 22, 2002 at 03:55:39PM +0100, Peter Crowther wrote:
I can't find out how to write a destructor or something functionally equivalent.
Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object.
Finalize did get some nice matches. Does finalize get called right away, or only when squeak does the GC? And if so, am I guaranteed that it'll be GCed that moment?
No. It happens whenenever the GC happens, which can be a long time.
One way to improve this is to manually invoke a GC if you get an error from being out of resources.
However, finalization turns out to be fairly limited with a typical garbage collector like Squeak's. It seems to work best as a protection against stupid mistakes during development, and not as a general programming technique. It's interesting to think about memory systems that can do better at this, but that's not practical right now. (Though, Squeak would be a fine platform for doing memory management experiments!!)
This really irritates me intellectually. Garbage collection works so beautifully for *one* type of resource at a time. Note that you can run garbage collections efficiently if you just wait until memory is low. However, how do you do this for multiple kinds of resources in addition to memory, while staying reasonably efficient? For example, suppose you have an application that *really* starts chewing through sockets without using much memory? Then collecting the sockets means collecting memory more frequently, which sounds inefficient.
It seems like garbage collection should generalize somehow, but I have absolutely no idea what that way would be.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I can think of.. so I must be missing something.
There are still things you can do. You can have "close" decrement a counter, and not do a real close until the counter reaches 0.
Lex
At 12:21 PM 10/22/2002 -0400, Lex Spoon wrote:
... However, finalization turns out to be fairly limited with a typical garbage collector like Squeak's. It seems to work best as a protection against stupid mistakes during development, and not as a general programming technique. It's interesting to think about memory systems that can do better at this, but that's not practical right now. (Though, Squeak would be a fine platform for doing memory management experiments!!)
This really irritates me intellectually. Garbage collection works so beautifully for *one* type of resource at a time. Note that you can run garbage collections efficiently if you just wait until memory is low. However, how do you do this for multiple kinds of resources in addition to memory, while staying reasonably efficient? For example, suppose you have an application that *really* starts chewing through sockets without using much memory? Then collecting the sockets means collecting memory more frequently, which sounds inefficient.
It seems like garbage collection should generalize somehow, but I have absolutely no idea what that way would be.
The best explanation I've ever heard for why you are unlikely to see garbage collection generalized in this manner was by George Bosworth of Smalltalk/V fame. George's explanation basically goes like this: Garbage collection is a resource management solution for a resource that fits a particular "economic" model (very large resource pool, each resource has a very low value (who cares if you loose a few bytes out of megabytes), very high churn rate, moderate wastage is acceptable, etc.). Garbage collection algorithms and policies are all designed and specifically optimized for this specific resource management problem and simply are not appropriate for the management of resources subject to a very difference set of economics. In addition, there is no reason to believe that there is a single universal resource management mechanism that can be used to optimally manage all types of resources.
The problem with finalization is that it applies memory resource management policies to other resources (like postgres connections) that have a very different set of economics associated with them.
Allen_Wirfs-Brock@Instantiations.com
--- Allen Wirfs-Brock Allen_Wirfs-Brock@Instantiations.com wrote:
The best explanation I've ever heard for why you are unlikely to see garbage collection generalized in this manner was by George Bosworth of Smalltalk/V fame. George's explanation basically goes like this: Garbage collection is a resource management solution for a resource that fits a particular "economic" model (very large resource pool, each resource has a very low value (who cares if you loose a few bytes out of megabytes), very high churn rate, moderate wastage is acceptable, etc.). Garbage collection algorithms and policies are all designed and specifically optimized for this specific resource management problem and simply are not appropriate for the management of resources subject to a very difference set of economics. In addition, there is no reason to believe that there is a single universal resource management mechanism that can be used to optimally manage all types of resources.
The problem with finalization is that it applies memory resource management policies to other resources (like postgres connections) that have a very different set of economics associated with them.
Allen_Wirfs-Brock@Instantiations.com
Well, that kind of argument encourages me to make my "other resources" really large in terms of memory consumption so that they cost roughly an appropriate amount when expressed in memory economics. I think a Postgres connection should be...umm...18Mbytes.
It seems to me that it would be a workable comprimise to use finalization for those objects which get/got handed around and are hard to track, but then something like an ensure: block to clean up the ones where that is easy to do. It seems to me that it would give you good performance in the common case, but then CYA (without requiring reference counting) in the complicated one. Does this just not work out well in practice?
-andrew
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
At 04:08 PM 10/22/2002 -0700, Andrew Berg wrote:
It seems to me that it would be a workable comprimise to use finalization for those objects which get/got handed around and are hard to track, but then something like an ensure: block to clean up the ones where that is easy to do. It seems to me that it would give you good performance in the common case, but then CYA (without requiring reference counting) in the complicated one. Does this just not work out well in practice?
It's probably more appropriate to use finalization as a debugging aid to catch "leaks" in your connection resource management scheme. Remember that garbage collectors generally make no guarantees about their latency in running finalizers. You may empirically discover that your scheme usually works but you still won't want to be caught by a "phase of the moon" change in GC latency. It's this unpredictability that generally makes finalization based resource recovery mechanism unreliable.
Allen_Wirfs-Brock@Instantiations.com
Ragnar Hojland Espinosa writes:
On Tue, Oct 22, 2002 at 03:55:39PM +0100, Peter Crowther wrote:
I can't find out how to write a destructor or something functionally equivalent.
Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object.
Finalize did get some nice matches. Does finalize get called right away, or only when squeak does the GC? And if so, am I guaranteed that it'll be GCed that moment?
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
You might want to try using blocks e.g.: connectionPooler withConnection: [:conn| the code that uses the connection "conn"].
This way the method withConnection: can both open the connection and close it. This is a fairly standard idiom to wrap creation and deletion of a resource.
I'm guessing you will have to write your own connection pooler but this will give you limited scope access to that connection. It can excape (but that could happen via a pointer in C++ as well).
Bryce
Bryce Kampjes bryce@kampjes.demon.co.uk is claimed by the authorities to have written:
You might want to try using blocks e.g.: connectionPooler withConnection: [:conn| the code that uses the connection "conn"].
This way the method withConnection: can both open the connection and close it. This is a fairly standard idiom to wrap creation and deletion of a resource.
Don't forget #ensure: as in [file _ filename openfile. things doStuff] ensure: [file close] which will close the file even if the code in the receiver block does a non-local return.
tim
On Tuesday 22 October 2002 09:48 am, Bryce Kampjes wrote:
You might want to try using blocks e.g.: connectionPooler withConnection: [:conn| the code that uses the connection "conn"].
And note that you probably want to do
aBlock fixTemps
before you save aBlock (due to Squeak's current lack of real closures).
Ragnar Hojland Espinosa wrote:
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I can think of.. so I must be missing something.
pgsqueak-0.7.0 has been stuck at 0.7 for over a year. Improved error handling is on the todo list, the design intent is that the connection object would keep track of the connection state, and re-connect if necessary. A connection pool manager would hold a bunch of these connections.
In the absence of a connection pool, I used a singleton. I would terminate the connection, before re-starting it. If the connection were already bad (maybe because I'd just restarted the image), then you'd get an error right away. Ignore the error, and restart the connection. IIRC, you might have to tweak things because the socket may be dead, but the connection object has not nil'ed out its socket instance var.
--yanni
Ragnar Hojland Espinosa ragnar@linalco.com wrote:
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I can think of.. so I must be missing something.
Finalization works as well as it can, but unfortunately that isn't wonderfully well. For handling resources other than memory, e.g. database connections, it is usually better if you can work out a way to do it manually.
In this case, maybe it can be done without needing to put #close's everywhere. Key in on "maintaining a db connection pool". Make an object DBConnectionPool which keeps track of all open connections, and have everyone query this object when they want an open connection to use. Have this object periodically check if it has any idle connections, and close a few if necessary. Similarly, have it open a few whenever that seems appropriate.
I hope this idea works out for your situation. I'm sure this idea is discussed on the WWW -- it's a common problem!
Lex
Lex Spoon writes:
Ragnar Hojland Espinosa ragnar@linalco.com wrote:
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
Finalization works as well as it can, but unfortunately that isn't wonderfully well. For handling resources other than memory, e.g. database connections, it is usually better if you can work out a way to do it manually.
The idiom that popped up last time was:
connectionPool withConnection: [:conn| do the work].
withConnection should get a new connection from the pool and also return it to the pool. Be sure to use ensure: to make sure that the connection is returned even if an exception occurs as Tim suggested last time.
This at least gives you lexically scoped access to resources in a sensibly scoped manner. That is what C++ finalisation really buys you.
There was a good discussion about using finalisation and why it's not a good technique about a year ago. It started with a similar question about database connection finalisation.
Bryce
There is a way in Java to use WeakReference and ReferenceQueue to detect connection leaks and such and recover from them. Does Smalltalk have a similar mechanism?
Thanks,
-joel
----- Original Message ----- From: "Lex Spoon" lex@cc.gatech.edu To: squeak-dev@lists.squeakfoundation.org Sent: Tuesday, July 08, 2003 6:34 AM Subject: Re: destructors, how?
Ragnar Hojland Espinosa ragnar@linalco.com wrote:
The thing is.. I'm leaving behind lots open postgres connections which
would
be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too
many
open, and things suddely get very ugly.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I
can
think of.. so I must be missing something.
Finalization works as well as it can, but unfortunately that isn't wonderfully well. For handling resources other than memory, e.g. database connections, it is usually better if you can work out a way to do it manually.
In this case, maybe it can be done without needing to put #close's everywhere. Key in on "maintaining a db connection pool". Make an object DBConnectionPool which keeps track of all open connections, and have everyone query this object when they want an open connection to use. Have this object periodically check if it has any idle connections, and close a few if necessary. Similarly, have it open a few whenever that seems appropriate.
I hope this idea works out for your situation. I'm sure this idea is discussed on the WWW -- it's a common problem!
Lex
On Saturday 12 July 2003 09:05 pm, Joel Shellman wrote:
There is a way in Java to use WeakReference and ReferenceQueue to detect connection leaks and such and recover from them. Does Smalltalk have a similar mechanism?
Yes, we have a number of weak collection classes. For instance, we have dictionaries in which either the key or the value is weak. The remaining value or key can be used to identify (or clean up after) the object that just got GC'd.
In the past, there have been some fairly fierce debates about the kind of licenses we should be using with Squeak code. In particular, the point was made by me and others that LGPL was appropriate, if at all, only for libraries associated with a plugin. Many felt that LGPL would not have the GPL-like viral impact in the context of an object-oriented monolithic system. While many of these points seemed valid, my instincts led me to take a substantially more conservative approach, suggesting that --at most-- we should permit Squeak-L/LGPL dual licenses for such code.
I am once again concerned about the use of LGPL for squeak code, in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL. As understood from skimming blogs discussing the issues, Apache foundation has opted to eschew LGPL libraries, in part, because of this FSF gloss.
There is a thread on Slashdot discussing this at present: http://developers.slashdot.org/article.pl?sid=03/07/17/ 2257224&mode=thread&tid=108&tid=117&tid=126&tid=156&tid=99
On Fri, 2003-07-18 at 03:01, Andrew C. Greenberg wrote:
in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL. As understood from skimming blogs discussing the issues, Apache foundation has opted to eschew LGPL libraries, in part, because of this FSF gloss.
Of course, this is largely political rather than legal. First, the FSF is bound to give the widest possible interpretation of their own (politically inspired) license; second, the ASF is not bound to go into a public fight with an entity that lots view as a sort of sibling organization.
Jar files are very similar to shared libraries, and when studying the LGPL in respect to Java development years ago, I concluded that binding .jar files would fall under clause 6. For Squeak, the situation is much muddier, because we currently have no way to get the 'anti-viral' protection offered by clause 6.
What I do wonder about: what's the fuzz? Clause 6 is *exactly* the clause that protects the 'host' program against the library w.r.t. virality, so this should be *good* news for the Java community (well, now news - lots of us already new this since, say, 1995). Did no-one read the news post on gmane.org and then the LGPL?
On Friday, July 18, 2003, at 03:43 AM, Cees de Groot wrote:
On Fri, 2003-07-18 at 03:01, Andrew C. Greenberg wrote:
in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL. As understood from skimming blogs discussing the issues, Apache foundation has opted to eschew LGPL libraries, in part, because of this FSF gloss.
Of course, this is largely political rather than legal. First, the FSF is bound to give the widest possible interpretation of their own (politically inspired) license; second, the ASF is not bound to go into a public fight with an entity that lots view as a sort of sibling organization.
Then why should we?
Am Freitag, 18. Juli 2003 17:11 schrieb Andrew C. Greenberg:
On Friday, July 18, 2003, at 03:43 AM, Cees de Groot wrote:
On Fri, 2003-07-18 at 03:01, Andrew C. Greenberg wrote:
in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL. As understood from skimming blogs discussing the issues, Apache foundation has opted to eschew LGPL libraries, in part, because of this FSF gloss.
Of course, this is largely political rather than legal. First, the FSF is bound to give the widest possible interpretation of their own (politically inspired) license; second, the ASF is not bound to go into a public fight with an entity that lots view as a sort of sibling organization.
Trolling: I guess next time they attack squeak-license as viral, because Squeakers see everything as core-parts of squeak? Have some good time trying to correct the misunderstandings then..
FSF clarified: People must be able to modify the library and use it in the application. So for example external jars are ok. Seems some cheaters thought: The LGPL states, if i link to the library i have to publish my library-patches. Java does not link..
Franz (lisp) had similar problems with c-oriented terminology. They addressed a preamble to LGPL here http://opensource.franz.com/preamble.html
Then why should we?
Because a lot of condig non-lawyers know its implications, while they have to hire a lawyer again to understand sequakl's license. instead of just clarifiing some words like "linking"
-Volker
Hi,
with all the problems (esp. GPL) and Smalltalk, I really think there should be a "standard" Open Sourcish License for the wider Smalltalk community.
It has been a long tradition for smalltalkers to provide Goodies for free wirh sourcecode, but they never bothered to set up a "license culture": There's lots of great stuff out there, and acually either it's pretty unclear how the stuff is licensed (SmaCC, refactoring Browser, and the whole "Camp Smalltalk" stuff). Or it's even GPLed/LGPLed. Actually, I have no idea how SUnit is licensed...
The whole situation would be *much* clearer if there would be some "Free Smalltalk Community License" *and* a culture/community of using this for all the Open Source Smalltalk projects. And, as we see with SmaCC, the Squeak License is *not* this License: It's tied to much to squeak itself. This may not be a problem from a lawyer point of view, more something cultural...
Marcus
On Thu, Jul 17, 2003 at 09:01:41PM -0400, Andrew C. Greenberg wrote:
In the past, there have been some fairly fierce debates about the kind of licenses we should be using with Squeak code. In particular, the point was made by me and others that LGPL was appropriate, if at all, only for libraries associated with a plugin. Many felt that LGPL would not have the GPL-like viral impact in the context of an object-oriented monolithic system. While many of these points seemed valid, my instincts led me to take a substantially more conservative approach, suggesting that --at most-- we should permit Squeak-L/LGPL dual licenses for such code.
I am once again concerned about the use of LGPL for squeak code, in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL. As understood from skimming blogs discussing the issues, Apache foundation has opted to eschew LGPL libraries, in part, because of this FSF gloss.
There is a thread on Slashdot discussing this at present: http://developers.slashdot.org/article.pl?sid=03/07/17/ 2257224&mode=thread&tid=108&tid=117&tid=126&tid=156&tid=99
Hi. How can I set max dimension of a project? I've a project in 1024x768 and I've to view it in a screen 800x600, without scrolling or hided objects. So, how can I set dimension of a project's screen?
Thank you
Chobin
Am Freitag, 18.07.03 um 10:59 Uhr schrieb Chobin:
Hi. How can I set max dimension of a project? I've a project in 1024x768 and I've to view it in a screen 800x600, without scrolling or hided objects.
The project itself does not have any size, it always fills the Squeak window. Since projects are not scaleable, you are out of luck viewing a project designed for 1024x768 on a 800x600 screen.
What some folks do is to grab a Ruler from the Object catalog's "useful" category and place it in the upper left corner of the screen. You can resize it to your liking, send it to the back, and lock it. This serves as a visual aid for laying out your stuff.
So, how can I set dimension of a project's screen?
Not sure what you mean here. What should work to adjust Squeak's window size is this:
DisplayScreen depth: 32 width: 800 height: 600 fullscreen: false
However, it is unimplemented on Linux and buggy on Mac (it resizes the screen even if fullscreen is false, instead of only the window).
-- Bert
On Thursday 17 July 2003 06:01 pm, Andrew C. Greenberg wrote:
I am once again concerned about the use of LGPL for squeak code, in view of the positions recently taken by FSF with respect to LGPL and Java-based libraries, which has taken the view that clients of "included" Java libraries are virally attached by LGPL.
Hi Andrew,
Just a quick glance at SqueakMap shows me that few packages seem to be under LGPL.
I hadn't realized that StarBrowser was listed as LGPL (or if I did I forgot). I've written Roel to see if he would be willing to change it to something else (MIT?).
Do you think that even having LGPL packages pointed at by SqueakMap is a problem, or is it just their use you're concerned about?
Thanks,
You could consider a manual garbage collection to free up those resources. I'm not a GC guru, so I can't guarantee it will do what you want, but I'd give it a try. I believe the method is on ObjectMemory somwhere.
Ragnar Hojland Espinosa wrote:
On Tue, Oct 22, 2002 at 03:55:39PM +0100, Peter Crowther wrote:
I can't find out how to write a destructor or something functionally equivalent.
Check out implementors of 'finalize' (IIRC). In essence, you hold onto the object using a weak array; are notified when it is garbage-collected; and clear appropriate fields based on copies of the data in the object.
Finalize did get some nice matches. Does finalize get called right away, or only when squeak does the GC? And if so, am I guaranteed that it'll be GCed that moment?
The thing is.. I'm leaving behind lots open postgres connections which would be nicely closed with a "destructor", and right now I don't know how to automatically close (maybe you cant?) when it should (the sooner the better). Obviously, postgres complains quite loudly when you have too many open, and things suddely get very ugly.
Ah well.. at least I can add the closes by hand :/ but that means leaks and sort of rules out to have decent db connection pools in any way I can think of.. so I must be missing something.
squeak-dev@lists.squeakfoundation.org
-
Allen Wirfs-Brock -
Andrew Berg -
Andrew C. Greenberg -
Bert Freudenberg -
Bryce Kampjes -
Cees de Groot -
Chobin -
Jason Dufair -
Joel Shellman -
Lex Spoon -
Marcus Denker -
Ned Konz -
Peter Crowther -
Ragnar Hojland Espinosa -
Tim Rowledge -
Volker Nitsch -
Yanni Jew