On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote: > As I wrote in the last post, this isn't what I'm talking about. I'm talking > about destroying the object before the GC does. Yah, so am I. I'm just saying that after the object is destroyed, don't keep it around. > Yeah, what about a nasty module that decides not to call the GC and blow > your memory??? That's IMO the best thing about programming in Perl compared > to C: not having to keep track of the memory!!! RFC 28!!! Whoh! I never meant to say that Perl shouldn't automaticly do GC as it feels like it. Simply that you should be able to explicitly garbage-collect if you want to. (It's arguable that you should be able to disable automatic GC. In any case, it should be tunable, so disabling it is just an _extreme_ tune.) > We must not count on the programmer for almost nothing. Watch your double-negitives. Writing calmly helps. > > If the programmer > > can GC when /he/ wants to, he can do so when the pause will have the least > > effect. > I agree the programmer should have how to explicitly call the GC, but that > wouldn't be required from him. OK then, we're all in agreement. > > Think of a program that you want to run near-realtime most of the time, > Write C. With no GC below it. Probably, with no OS (or a realtime one) below > it. Sorry. Near-realtime is apparently a much more restrictive word then I wanted. > > but > > where you have a bit of downtime every now and again. A game comes > > immedetly to mind. > > Even if you want to write games in Perl (I would definitely want to), you > should use C extensions to do the screen update (at least for speed...), and > those would definitely not be constrained to GC pauses. True, but I probably wouldn't for the event loop, and certianly not for the tick function. (At least some of the tick functions.) > Call the GC explicitly before, no need to control when *not* to call it for > this, as you were suggesting. > Serious, man. Not having a implicit GC is not having GC at all! And as Perl > should be Perl, it should keep collecting our garbage as we produce it! Sorry. I should have explained my wording more carefuly. I see three different types of triggers: 1) Explicit -- A call to garbage::collect or somesuch. 2) Implicit -- Certian program-execution events implicitly do a GC run when encountered. For example, you could say we do this now -- we garbage-collect every time a scope exits. What I was suggesting above is that when a 1-arg undef is encountered, implicitly GC. 3) Automatic -- Certian runtime events, not directly (or obviously) related to the flow of execution, like when the number of SVs created or the amount of memory allocated since the last GC run exced a certian critical value. (I /think/ a dictionary would agree with me, but I'm not about to get pissy and look them up.) I was saying that we should do 1 and 3, but not 2. -=- James MastrosThread Previous | Thread Next