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 Mastros
