[moved to dev list]

Philippe M. Chiasson wrote:

Michael Schout wrote:
Michael Schout wrote:

MP_CODE_ATTRS() doesn't work under perl 5.10.0.
Does anyone have any ideas on how to fix this?

Short answer, not yet.

Slightly longer answer follows.

The problem is that the different flavors of filter handlers need to
be identified, and at that point, all that we got it a CV *.

Using the hack you pointed out, we were able to piggyback to some
unused portion of the CV*. Unfortunately, in 5.10, that field is now
a union between 2 fields, so that no longer holds true.

The solution will be to either find a new way to attach this information
to a CV (I looked around, and nothing jumped at me), or we'll have to switch
to storing this information separate of the CV itself (a cleaner, but 
potentially
annoying solution).

I was digging into this today trying to increase my knowledge of perl/mod_perl internals and I think I have grokked what you said here about why it is broken with 5.10.0.

As far as someplace to store this information separately, I'm going to go out on a limb here and look like I don't know what I'm talking about, but here goes, maybe at least I will learn something :)

1) add 'MpHV * codeattrs' somewhere ifdefined for perl > 5.9.5, to store the code attrs along with package name. maybe server_config is the correct place for this?

2) change MP_CODE_ATTRS macro to accept a package name SV rather than a CV. Use that SV to grab the corresponding value from codeattrs

3) in modperl_mgv.c line 274,
'hander->attrs = (U32)MP_CODE_ATTRS(name);'

4) in Apache2__Filter.h line 91,
'return (U32 *)&MP_CODE_ATTRS(package);'

I think I at least understand what you mean by this being an annoying solution. Storing this information separate of the CV seems like access to a pool object in some form is going to be needed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to