You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl-cvs@perl.apache.org by st...@apache.org on 2003/11/18 00:00:34 UTC
cvs commit: modperl-2.0/todo bugs_apr_ext bugs_build bugs_mp bugs_registry release features_maybe features_missing features_new design_notes
stas 2003/11/17 15:00:34
Added: todo bugs_apr_ext bugs_build bugs_mp bugs_registry
release features_maybe features_missing
features_new design_notes
Log:
bugs/issues reorg, plan 2.0 release. work in progress
[worked out by Geoff, Philippe, Stas in Vegas]
Revision Changes Path
1.1 modperl-2.0/todo/bugs_apr_ext
Index: bugs_apr_ext
===================================================================
########################################
# external (non-mod_perl) APR:: issues #
########################################
* As mike chamberlain told me over irc, apr-ext/perlio was faling for
him because of the modperl_perl_gensym not being resolved in
APR/PerlIO.so. I didn't see that error since on linux by default
symbols resolution is lazy and since that part of the api wasn't
tested I did see the problem. On MacOSX the loading is RTLD_NOW
(non-lazy) so it detects any missing symbols problems immediately.
Luckily DynaLoader allows us to force the non-lazy mode by setting
an env var: PERL_DL_NONLAZY=1. We need to force this env variable on
when building with MP_MAINTAINER=1. I suppose that it should be
added to the autogenerated t/TEST and t/SMOKE. and to
t/conf/modperl_extra.pl ($ENV{PERL_DL_NONLAZY}=1) so it affects the
server-side as well as the client-side (normally env var aren't
propogated to the server).
* APR::Table now depends on modperl_hash_tie, so it can't be used
outside mod_perl. should probably abstract this function into a new
utils.c object that can be linked by APR.so.
Status: see the next item
* APR::PerlIO needs an equivalent of modperl_perl_gensym
Status: we need to abstract those function into a separate object,
which can be linked by APR.so. However I think we should probably
provide a static build and after that see how to do the linking
right. Otherwise we may have collisions with statically linked
symbols and the dynamic ones.
APR::Pool relies on interpreter management functions and therefore
can't be used outside mod_perl.
Status:
1.1 modperl-2.0/todo/bugs_build
Index: bugs_build
===================================================================
#######################
# Build/Startup Issue #
#######################
OS Ver Mod Comments
----------------------------------------------------------------------
OpenBSD 2.9 DSO Builds but won't start, with segfaults in the
Perl lexer. I wasn't even able to start mp1-dso with
the customly built perl (tried 5.6.1 .. 5.9.0)
-- the segfault is again in lexer. It seems that
the standard OpenBSD perl package has been heavily
patched, when the core system perl 5.6.0 package was
built, since I can run 'make test' on mp1-dso, but not
with a customly built 5.6.0 with the same
options. Since 2.9 is no longer supported by OpenBSD,
there is no 5.6.1 or higher to try, so at this moment
we simply give up on 2.9. We think that the static mp2
build should work just fine (once it's available).
AIX 3.3 DSO Works with -berok to ignore linking errors (symbol
resolution). Should replace -berok with a proper
symbol resolution at linking time, but I had not much
success with using this approach (dlopen fails).
FreeBSD ?? DSO Works with non-threaded perl (4.8-RELEASE and
5.1-RELEASE)
http://marc.theaimsgroup.com/?l=apache-modperl&m=106399870822612&w=2
It doesn't work with threaded perl/worker mpm,
seemingly because of the problems with threads on
FreeBSD (not sure what version).
* we should stop generating xs/apache_*, at least for a reason that
it's incomplete and will be never complete as we don't keep up with
changes with ap_/apr_ namespace. Also we don't have the logic to
handle cases where functions aren't available on certain
platforms. Importing these unavailable functions may cause loading
problems on some platforms (aix?). If developers need to import
symbols from ap_/apr_ namespace they should use .exp files installed
by httpd/apr/aprutil.
* gcc 3.3 (from cvs 2003-07-28) supports a new option:
-Wdeclaration-after-statement, which we need to enable in the
maintainer mode, to catch any declarations after statements, since
by default gcc doesn't complain about them. Probably need to wait
till gcc-3.3.2 and enable it then.
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?r1=2.639&r2=2.640&f=h
* Testing:
Need to put Philippe's smoking test into the core
-- shouldn't forget to test with perlio enabled and disabled
* mp2bug -- add the output of 'ldd httpd' to the report
1.1 modperl-2.0/todo/bugs_mp
Index: bugs_mp
===================================================================
#################
# mod_perl bugs #
#################
* PassEnv/SetEnv propogation in <Perl> section
http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_BUG%5D_PerlPassEnv_issues_P70500/
* we have a dependency check problem when xs/*/*.h use code from
xs/modperl_xs*.h, when the latter change 'make' won't rebuild the
dependant files
* most of the xs wrappers print no "Usage: " when wrong args/wrong
number of args are passed, would be nice to add the usage message
whenever incorrect arguments error is logged. e.g., when
APR::URI->parse() gets the wrong first arg (non-pool) it prints:
p is not of type APR::Pool at ...
whereas it's not so obvious that the function expected the pool
object, neither it specifies which ("arg number") of the arguments
is wrong.
possible solution: add a new field to the map files, which will be
used as a usage message whenever an argument error occurs.
* 'SetHandler modperl' doesn't reset $|, so if anything turns it on
anywhere, it's going to stay that way. Meaning excessive flushing
probably causing a performance hit. I've tried to add the code to
reset it, but this requires getting a perl interpreter at the early
stage and it breaks several filter tests, which has relied before on
the coincidence that both the response handler and the filter were
run by the same interpreter (in particular this breaks the code
where push_handlers() uses a string as a handler, rather a CODE
reference, see t/filter/TestFilter/both_str_rec_add.pm, to
reproduce the problem, simply s/modperl/perl-script/)
* $r->rflush doesn't work. see:
http://marc.theaimsgroup.com/?l=apache-modperl&m=103847990813285&w=2
I also see a weird behavior where it does sends FLUSH buckets but
they all seem to fall through the data, thus not really flushing
anything. this can be easily reproduced with MyApache::FilterSnoop.
* Apache::Log compat issues:
Apache->warn, Apache::warn, Apache::Server->warn and
Apache->Apache::Server->log_error are all doing:
s = modperl_global_get_server_rec();
and this function is thread safe only during the startup.
possible solutions:
1) enforce that these functions are used only at the server startup
2) require +GlobalRequest, which gives us r->server, now thread
safe (though slow).
3) drop them all from the API and move to compat.
[remember that Apache::warn is needed for registry scripts to
override warn()]
For Apache::warn and registry, the solution is to supply
GLOBAL::CORE::warn for the current request and get $r inside of it
and]
Report: Message-ID: <Pi...@mako.covalent.net>
Status: <img alt="Doug, contemplating">
* see if we can avoid touching environ[] until a fork() from Perl
happens
1.1 modperl-2.0/todo/bugs_registry
Index: bugs_registry
===================================================================
##########################
# Registry specific bugs #
##########################
* protect registry classes from bad scripts which try to assassinate $r
Report: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106153785129782&w=2
Status: (stas) i'm not sure whether we really need this feature,
since it's the first time in the last 6 years we had a
problem with bad user code of this kind. let's keep it in
the patches until we have a real need for it.
Priority: very low
1.1 modperl-2.0/todo/release
Index: release
===================================================================
##################################################
# Things to be resolved for mod_perl 2.0 release #
##################################################
* static build - if we make it working on OpenBSD, AIX and FreeBSD,
then it's not important to fix the DSO issues, otherwise make the
DSO issues a release issue.
* perl Makefile.PL PREFIX=/foo/bar works fine, however Makefile.PL'll
still refuse to build unless MP_INST_APACHE2=1 is passed. It should
refuse to do so only if it finds mod_perl 1.0 installed under that
PREFIX, which can be a tricky check, since the exact logic to figure
out the paths is deep inside EU::MM. Probably it's better to run
'File::Find' and search for 'mod_perl.pm' under PREFIX, if found
check its version and assert only if it's 1.xx
* META.yml. Generate META.yml (make dist does that), add Apache-Test
as a private resource, so it won't be attempted to be indexed by
PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to
overwrite META.yml.
* <Perl> sections:
A few issues with <Perl> sections:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2
* Recursive <Perl> sections:
http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_-_BUG_%5D_Issue_handing_Apache_config._error_messages_P70501/
and
http://mathforum.org/epigone/modperl/dartrimpcil
* Fixing Apache->warn("foo")
Report: http://mathforum.org/epigone/modperl-dev/noxtramcay/3D11A4E5.6010202@stason.org
Thread: http://mathforum.org/epigone/modperl-dev/noxtramcay
Status: pending Apache::Log compat issues, this and other methods
might be dropped.
* per-server cleanups core dump or are otherwise ineffective
Apache->server->process->pconf->cleanup_register(sub { ... });
Report: geoff
* Looks like there is an issue with filter configuration, I've noticed that:
PerlInputFilterHandler MyApache::InputFilterGET2HEAD
silently ignores the filter, whereas:
^^^^^^^^^^^^^^^^
PerlInputFilterHandler +MyApache::InputFilterGET2HEAD
calls the filter. figure out:
- why the loading doesn't happen
- why the error doesn't happen (probably both connected)
* Currently modperl_filter_add_{connection|request} check the filter
handler function attrs before accepting the filter. If the module
wasn't preloaded the check fails and filter handler is skipped. We
could have this issue documented (which is OK, but might raise too
many questions), but we could also always preload the filter
handlers. To test see TestFilter::input_msg
* child processes never run END blocks. a good example is
Apache::TestUtil, which doesn't cleanup files and dirs it has
created, because the END block is not run.
also: see the next item
* ModPerl::Registry END {} block woes , described in details at the
forwarded message from Jim Schueler
http://marc.theaimsgroup.com/?l=apache-modperl&m=103720834717981&w=2
the whole thread is here:
http://marc.theaimsgroup.com/?t=103713532800003&r=1&w=2
* we still have a problem with mod_perl starting from a
vhost. consider the following config:
PerlSwitches -I/foo/bar
<VirtualHost TestDirective::perlloadmodule6>
PerlLoadModule TestDirective::perlloadmodule6
...
</VirtualHost>
The value set by PerlSwitches in the main server is ignored, because
it's not seen by mod_perl starting from vhost.
overall, currently the early startup in vhost is a bunch of ugly
workaround, which I've added everytime I came up with a config that
wasn't working. Need to come up with a better design decisions.
once this is fixed. I want the perlloadmodule6 to be loaded before
all other perlloadmodule configs, because it tests an important
segfault when perlloadmodule happens to start mod_perl from within a
vhost. but because PerlSwitches from other tests are ignored, it
can't trigger the mod_perl startup in the test suite.
- anonymous handler (for push_handlers, add_input_filter, etc), see
modperl_mgv.c: modperl_mgv_name_from_sv
- PerlModule, PerlRequire, Perl{Set,Add}Var in .htaccess is missing
Owner: geoff
- cgi emulation: %ENV management:
- %ENV is currently only saved/restored for the perl-script
handler, i.e. changes to %ENV outside of a perl-script handler
are not cleared. of course, "clean" modules would use local() to
modify %ENV, but there should be an option to save/restore
globals outside of the perl-script handler
STATUS: do the cleanup for all handlers, but provide a new config
option so users can disable it if they know what they are doing.
* Apache::SizeLimit and Apache::Resource
* It'd be nice to have PAUSE and the clients support packages with
several versions, like mod_perl 1.0 and mod_perl 2.0, since once we
release it any dependency on mod_perl will be resolved as mod_perl
2.0, when mod_perl 1.0 may be required instead.
1.1 modperl-2.0/todo/features_maybe
Index: features_maybe
===================================================================
#########################
# Nice to have features #
#########################
* PerlPreConnectionHandler is implemented, but the 'void *csd' arg in
the callback is ignored. will require a modification of
modperl_callback_run_handlers to pass yet another optional argument.
Status: most likely nobody will ever want to use this option, so
don't waste time working on it.
1.1 modperl-2.0/todo/features_missing
Index: features_missing
===================================================================
########################
# mp1 missing features #
########################
* Apache::PerlSections->dump
It does exist, but it's a completely internal function, not dumping existing configuration
as it used to be in 1.x. (needed by Apache::Status, for instance). Need to be implemented
and the existing dump method must be moved out of the way
* directive handlers are supported but need some work for 1.x compat
- Apache::ModuleConfig->get needs a compat method mapping to
Apache::Module->get_config
- Apache::CmdParms::{GETC,getline} needs compat mapping, similar to
what Apache::Directive->as_string does, but one char or line at a time
* Apache::PerlSections missing features for backwards compatibility:
- $Apache::ReadConfig::DocumentRoot
- Apache::PerlSections->store(filename)
Report: Philippe M. Chiasson <go...@cpan.org>
Status: Philippe M. Chiasson <go...@cpan.org> is working on it
* PerlOpCodeMask (experimental in 1.xx)
* die 404 (consider deprecating it)
* mod_perl.pm::import
- Apache::test: tobe a compat stub around new test framework
- Apache::src: tobe a compat stub around new build framework
1.1 modperl-2.0/todo/features_new
Index: features_new
===================================================================
#######################
# New features in mp2 #
#######################
* filters tie handle/perlio interface
both input/output filters should provide a tiehandle and/or perlio
interface.
Perl tiehandle methods include the following, '+' indicates must have, '-'
indicates not possible / doesn't make sense (though might require noop
stubs), '~' indicates would be nice if possible, '?' indicates unsure:
+ TIEHANDLE
+ PRINT
+ PRINTF
+ WRITE
+ READLINE
+ GETC
+ READ
+ CLOSE
? UNTIE
? DESTROY
+ BINMODE (noop)
? OPEN
~ EOF
- FILENO
~ SEEK
~ TELL
* maybe functions in xs/maps/(apache|apr)_functions.map
1.1 modperl-2.0/todo/design_notes
Index: design_notes
===================================================================
(dunno where to put it but don't want to lose these design notes, so
just land them here for now)
Filters: direct C api mapping
--------------------
Apache::register_output_filter($filtername, $callback, $filter_type)
Apache::register_input_filter($filtername, $callback, $filter_type)
filter_type can be one of:
Apache::FTYPE_CONTENT
Apache::FTYPE_HTTP_HEADER
Apache::FTYPE_TRANSCODE
Apache::FTYPE_CONNECTION
Apache::FTYPE_NETWORK
$r->add_output_filter($name, $ctx)
$c->add_output_filter($name, $ctx)
$r->add_input_filter($name, $ctx)
$c->add_input_filter($name, $ctx)
note: $ctx will default to NULL
Filters: directives
----------
PerlInputFilterHandler
PerlOutputFilterHandler
each will be the equivalent of:
ap_register_{input,output}_filter($handler_name, $handler, $filter_type)
where:
$handler_name is the Perl name, at the moment is "MODPERL_OUTPUT" and
"MODPERL_INPUT", would be easy to switch that to the handler name
$handler is the modperl C callback
$filter_type defaults to AP_FTYPE_CONTENT, subroutine attributes can
be used to specify the filter_types list above
based on attributes, add_{input,output}_filter may need to happen at
different times, e.g. input filters who want to filter headers +
content vs. input filters who want to filter only content
alternative to those directives would be:
PerlInputFilter
PerlOutputFilter
combined with:
SetInputFilter
SetOutputFilter
pros: can use Perl{Input,Output}Filter to register the filter in
httpd.conf, rather than using the API. can then call
$r->add_{input,output}_filter($filter_name) at request time
cons: in the common case, requires two directives that use the same
values (the $handler_name)
- and/or -
PerlSetInputFilter
PerlSetOutputFilter
as aliases for SetInputFilter, SetOutputFilter which also take care of
filter registration (which PerlInputFilter, PerlOutputFilter would
have done)
pros: similar to Set{Input,Output}Filter
only need to use one directive
cons: the filter module needs to register the filter in order to add
the filter at request time without using a directive
however: PerlModule Apache::FooFilter
where Apache::FooFilter registers the filter, can provide this
functionality without requiring new Perl{Input,Output}Filter
directives
- in any case -
with the C api mapping it should be possible for a PerlModule to
register the filter(s), then use the standard Set{Input,Output}Filter
directives and the add_{input,output}_filter api at request time.
note: no need to maintain a list of PerlFilters (like PerlModule,
PerlRequire) since the directives trigger modperl_handler_new(), just
like all other Perl*Handlers
Filters: {get,set,push}_handlers
-----------------------
would be nice for Perl{Input,Output}FilterHandler to work with the
modperl {get,set,push}_handlers api just like other Perl*Handlers