> And that's exactly what I need to do with "PerlOptions +Parent"...
This is how I support multiple code versions, when necessary. However, I strive to avoid this because it causes performance issues and makes server restarts take forever. > I need to support Windows which only supports some threaded MPM, This will cause you a lot of grief. As I understand things, the core perl interpreter supports threads and is thread safe. However, most of the modules available on CPAN are not thread safe. So, unless your application has no dependencies whatsoever(very unlikely) you're highly likely to encounter segmentation faults in production unless you use the prefork MPM. This is extremely unfortunate because it prevents us from using an MPM other than prefork in production. On Wed, Aug 7, 2019 at 10:20 AM Thorsten Schöning <tschoen...@am-soft.de> wrote: > Guten Tag André Warnier, > am Mittwoch, 7. August 2019 um 15:21 schrieben Sie: > > > In the PerlPostConfigRequire phase, there is no request yet, so there is > no "selected" > > VHost yet. > > (But maybe, yes, it does get executed once per "VirtualHost" in the > configuration; that, I > > really don't know. It may need to do that, just in case you have > specified an option that > > allocates a separate perl interpreter per VHost). > > And that's exactly what I need to do with "PerlOptions +Parent" anyway > and I can see in logs that my code behind "PerlPostConfigRequire" gets > executed without any request, has different environment variables per > request etc. I already implemented my former described approach and > things work (mostly) as hoped. > > > All the above being said, I am wondering why it bothers you so, that a > module is loaded > > and pre-compiled only when needed by the child/thread processing the > request. > > Performance is not my main concern, mod_perl/Perl/... simply breaks in > case too many concurrent requests arrive and need to compile my code. > I can easily reproduce that on Windows and Linux simply by using "ab" > and have that in production with different mod_perl-enabled apps. > > Details can be found in the following mail, but the only workaround I > found so far is to pre-compile the code during startup or simply to > not use mod_perl at all. The latter is not an option because some apps > implement mod_perl request handlers. > > > Syntax errors in case of threaded MPM and lots of concurrent requests. > > > http://mail-archives.apache.org/mod_mbox/perl-modperl/201907.mbox/%3C1116164701.20190731193313%40am-soft.de%3E > > > And if you do not want this extra overhead at all, can you not specify > all the module > > versions to be loaded, in the PerlPostConfigRequire directive ? > > That introduces manual maintenance overhead I would like to avoid. My > current implementation simply finds the dirs to its app based on the > current VHOST, iterates some files and forwards that to mod_perl to > load them. > > Works almost as expected, for some reason Perl still crashes at some > point during compilation of some packages. > > > P.S. There are definitely some deep and mysterious issues remaining with > mod_perl, when it > > is running under a threaded MPM. We use only prefork MPM with mod_perl, > for those reasons. > > I need to support Windows which only supports some threaded MPM, > unless I'm missing something. But simply using prefork might be a > workaorund on Linux I didn't think of... Going to give it a try if I > can't find the root cause for my current crashes. Thanks for the hint! > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
