Boris Zentner wrote:
Hi Stas,
Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
(gdb) bt
#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
val=0x0) at apr_hash.c:278
#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
at apr_hash.c:340
#2 0x40143d4
Am Donnerstag, 19. Februar 2004 09:51 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi Stas,
> >
> > Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
> >>>(gdb) bt
> >>>#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
> >>>val=0x0) at apr_hash.c:278
> >>>#1 0x40135c58
Boris Zentner wrote:
[...]
i.e. I can't reproduce your problem. Are you sure you are using the latest
cvs, did you run 'make install'?. There were quite a few changes in the
APR::Pool code over the last month.
Yes, Im sure. But for some reason It did not crash for me too. I investigate.
that's a
Hi Stas,
Am Donnerstag, 19. Februar 2004 11:03 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> >>i.e. I can't reproduce your problem. Are you sure you are using the
> >> latest cvs, did you run 'make install'?. There were quite a few changes
> >> in the APR::Pool code over the last month.
Hi,
Am Mittwoch, 18. Februar 2004 00:37 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>>my $c = shift;
> >>>$AUTOLOAD =~ /(\w+)$/;
> >>>$c->$1(@_);
> >>>
> >>>looks funny, but the we need to handle the return part too. That might
> >>> be not so nice for any case.
> >>
> >>Yes, that's not
Hi,
Am Mittwoch, 18. Februar 2004 00:47 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> Users who are after performance must not be penalized with this module
> being preloaded. So it should be configurable, with default to be On.
>
> We probabably can instrument EazyLife to dump a list of mod
I've brought it up before, but it looks like users are having real problems
with the way 2.0 hooks modules into the request phases.
in 1.0, module order was determined by compile-time ordering or
LoadModule/ClearModuleList/AddModule, neither of which exist in 2.0, where
Apache chose the HOOK_FIRST
Geoffrey Young wrote:
I've brought it up before, but it looks like users are having real problems
with the way 2.0 hooks modules into the request phases.
in 1.0, module order was determined by compile-time ordering or
LoadModule/ClearModuleList/AddModule, neither of which exist in 2.0, where
Apache
On Thu, 2004-02-19 at 19:56 -0500, Geoffrey Young wrote:
> [...]
> so, I'd like to suggest that at least for the request-time hooks we move
> mod_perl to APR_HOOK_REALLY_FIRST. this will give users similar behavior to
> the way mod_perl used to work in 1.0.
It does make sense to me and would actu
> Sounds fine to me.
k
>
> What happens if another module has also used REALLY_FIRST? You still
> can't ensure 100% that mp's handler will run first.
well, I'm going to play around with some constants and see how it all falls
out. REALLY_FIRST is just -10, so maybe MOD_PERL_REALLY_FIRST could
> I don't know about a compile-time option personally. I can just see it
> causing lots more problems than solving anything. It would introduce a
> huge number of basically different mod_perls, with different behaviour
> for the same user code, making bug tracking et all even more
> problematic.
11 matches
Mail list logo
