On 13/07/2006, at 8:33, Ali ISIK wrote:

> Hi, folks,
> I need some mod_perl wisdom regarding the current
> situation with inside-out classes.
> I am trying to compare, in particular, the following two:
> Class::Std
> Object::InsideOut
> I can see that O::I has advantages in
> o thread safety
> o (at least partial) foreign-inheritance support (the
> ability to inherit from non-inside-out classes)
> o speed (mainly due to array implementation of fields)
> o complete mod_perl support
> but I have some investment in Class::Std and I am
> trying to figure out whether I will have to convert my
> existing C::S CGI code to O::I for mod_perl compatibility.
> Are there any show-stoppers with C::S?
> I have seen some postings which declared Class::Std
> mod_perl-incompatible. The ideas put forth included:
> 1) crucial sub initialize() is in a CHECK block
> 2) custom :attributes break under mod_perl
> 3) some concerns about DESTROY
> I see that (1) may by now have been solved (is it?),
> as initialize() is now called from within new(), too.
> (2) seems to refer to :CUMULATIVE, :PRIVATE etc.
> Suppose I do not use these. Should I be ok, then?
> Are there any problems with the main :ATTR( ... )
> facility?
> How about (3) and other possible weaknesses?
> I may need foreign-inheritance (inherit from CDBI)
> and thread-safety (use fork() and port to Win).
> Is C::S totally hopeless in these respects?

My experiments and understanding is that Class::Std (also was my
preference and investment in coding) does not only fail on threads,
but forks as well. This means it can not work with mod_perl at all.

The reason is that the all important identifier is a memory location
- and that changes on write after a fork.

I have not actually tried using C:S with mod_perl - and other wiser
people may have better advice.

* - * http://www.osdc.com.au - Open Source Developers Conference * - *
Scott Penrose
Open source developer

Dismaimer: Open sauce usually ends up never coming out (of the bottle).

Please do not send me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Microsoft is not the answer. It's the question. And the answer is no.