Front page | perl.perl5.porters |
Postings from October 2003
Frankly I don't understand why internally Perl uses functions which aren't prototyped with (pTHX_ ...), and call dTHX; instead. Besides forcing on the application the overhead of calling PERL_SET_CONTEXT() every few millisecs in the env with multiple perl instances, any application always has an overhead of retrieving PERL_GET_CONTEXT. A good example of such a function is: Perl_safesysmalloc, which is called very often. There should be an alternative function which accepts the context as an argument, when it's available (which is true in most cases in perl guts). Ideally Perl internals shouldn't rely on the user to call PERL_SET_CONTEXT() and call it by itself only when needed. But I realize that it doesn't always work, e.g. when a redefined malloc is called by other parts of the non-perl program. I was told that calls to PERL_SET_CONTEXT/PERL_GET_CONTEXT are especially expensive in the multithreaded environment, because of the thread local storage management overhead. I would be interested to hear more about this from the threads experts. I wonder whether someone has benchmarked that overhead in the threaded environment. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.comThread Next