develooper Front page | perl.perl5.porters | Postings from August 2010

The need for perl_destruct()

Thread Next
From:
Reini Urban
Date:
August 2, 2010 13:47
Subject:
The need for perl_destruct()
Message ID:
AANLkTi=NJkROCr+gKC=2qQhHK8iTd_fYZHYrnVHAx6Hq@mail.gmail.com
I'm doing quite fine with breaking a new perl speed record.
exit() is free'ing my malloc'ed memory just fine, and I'm doing no embedding.
So:

int fast_perl_destruct( PerlInterpreter *my_perl ) {
    dVAR;
    VOL signed char destruct_level;  /* see possible values in intrpvar.h */
    HV *hv;

    assert(PL_scopestack_ix == 1);

    /* wait for all pseudo-forked children to finish */
    PERL_WAIT_FOR_CHILDREN;

    destruct_level = PL_perl_destruct_level;
#ifdef DEBUGGING
    {
	const char * const s = PerlEnv_getenv("PERL_DESTRUCT_LEVEL");
	if (s) {
            const int i = atoi(s);
	    if (destruct_level < i)
		destruct_level = i;
	}
    }
#endif

    if (PL_exit_flags & PERL_EXIT_DESTRUCT_END) {
        dJMPENV;
        int x = 0;

        JMPENV_PUSH(x);
	PERL_UNUSED_VAR(x);
        if (PL_endav && !PL_minus_c)
            call_list(PL_scopestack_ix, PL_endav);
        JMPENV_POP;
    }
    LEAVE;
    FREETMPS;
    assert(PL_scopestack_ix == 0);

    /* Need to flush since END blocks can produce output */
    my_fflush_all();

    if (CALL_FPTR(PL_threadhook)(aTHX)) {
        /* Threads hook has vetoed further cleanup */
	PL_veto_cleanup = TRUE;
        return STATUS_EXIT;
    }
    PerlIO_destruct(aTHX);
}

Missing is op_free (with attached sv_free), sv_clean_all,
and all the NULL setting of the globals.
So, what is the global destruction really needed for?

calling END blocks - call_list(PL_scopestack_ix, PL_endav)
tearing down threads
tearing down PerlIO, esp. flush (close is not really needed)

What else?
Calling DESTROY hooks is the big remaining feature, which is really required.
I'm thinking of a fast way to call all remaining DESTROY methods, but this
should be it. Or did I miss something else?

I don't care for freeing ops and svs, and esp. do not care for the
long winding road finding all. And in the B::C compiler most of those
are initialized static, so they don't need to be freed at all.

Note that long-running server processes make no difference. They never
reclaim memory,
only at then end of the long-running process. So it will grow and
grow, and "leaks" at the
end will just be reclaimed by the OS.
Just embedding is affected. I don't care for embedding.
-- 
Reini Urban

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About