perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject [mp2] pool object dependant methods insanity
Date Sat, 18 Dec 2004 17:08:26 GMT
[the previous thread was too long, starting a new one]

*** what methods need to be protected from dependent blocks going out
*** of scope ***

the following looks only at the first level (i.e. methods taking a
pool object):
-------------------------------------------------------------
*** returning objects ***

APR::Brigade:
- mpxs_apr_brigade_create

APR::Bucket:
- apr_bucket_alloc_create
- mpxs_APR__Bucket_setaside

APR::Finfo:
- mpxs_APR__Finfo_stat

APR::IpSubnet:
- mpxs_apr_ipsubnet_create

APR::Pool:
- mpxs_apr_pool_create (not sure about this one)

Apache::RequestUtil:
- mpxs_Apache__RequestRec_new

APR::Table:
- apr_table_copy
- apr_table_overlay
- apr_table_make

APR::ThreadMutex
- mpxs_apr_thread_mutex_create

*** returning strings ***

Apache::ServerUtil
- mpxs_Apache__ServerUtil_server_root_relative (once this is
   supported, we no longer need to double copy the string)

Apache::URI:
- ap_construct_server
- ap_construct_url

APR::URI
- mpxs_apr_uri_parse

Apache::Util
- ap_ht_time
- escape_path
-------------------------------------------------------------

as you can see most of these already use perl wrappers, so I can't quite 
see how this can be automated.

The biggest problem, that this is not enough. If the returned object (by 
one of the above methods) is used to create other objects/SVs,
the latter should be made dependant on the former too. e.g.:

   APR::Bucket::eos_create(APR::Bucket::alloc_create(APR::Pool->new)

the bucket allocator goes out of scope, before eos bucket, potentially
wiped out eos internals while there are still in use.

so if we try to identify all those, I think we are going to come up with a 
huge list of methods to fix. And most likely there will be 3rd and 4th 
levels as well.

Besides the problem of writing all this code, I think it may add a 
significant memory and CPU overhead.

Ideas for a better solution? We certainly can't leave things like there 
are, for example at the moment this perfectly well written code:

     $pool = APR::Pool->new();
     my $mutex = APR::ThreadMutex->new($pool);

will crash with apr built "--enable-pool-debug 
CPPFLAGS="-DAPR_BUCKET_DEBUG" (or in a real world application), since 
$pool goes out of scope before the mutex is destroyed.


-- 
__________________________________________________________________
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.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message