Mailing List Archive

Embperl and threaded mpm?
Hi all, just wondering if Embperl was ever made threadsafe so it could
work under Apache's event or worker apache mpm's.

The prefork does seem to limit somewhat the number of clients I can have
on my server, presumably due to the memory footprint (no shared code
between processes?).

It's been a while since I played with that stuff, so I've probably
forgotten some things that I should have written down "way back when" I
was developing the core website config in the early 2000's. Like,
exactly how shared is the memory for my Perl code between Apache's
preforked processes? I don't currently explicitly preload (Execute) all
of my Embperl code at startup, even though I have a switch for that in
my startup.pl, and it's been so long now (> 10 years) that I don't
remember why I disabled it. I do seem to remember that if you execute
all your files in startup.pl then it's shared at first, but then over
time that becomes more fragmented (non-shared)? Sorry to be so vague,
basically the way mod_perl/Embperl works with respect to how code gets
shared (or not) between processes has always been a bit murky to me, so
any tips would be appreciated.

Also, of course, whether event/worker is a thing I should be looking at
for Embperl at all.

Thanks!

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
AW: Embperl and threaded mpm? [ In reply to ]
Hi Neil,

Embperl is not working with threaded mpm.

Preloading all your perl code saves a lot of memory due to code sharing.

The main issue is, that you have to make sure, not to open any file or database connection or similar in the preload code, because that will be shared too, which does not work

Gerald


-----Ursprüngliche Nachricht-----
Von: Neil Gunton [mailto:neil@nilspace.com]
Gesendet: Sonntag, 25. Juni 2017 21:08
An: embperl@perl.apache.org
Betreff: Embperl and threaded mpm?

Hi all, just wondering if Embperl was ever made threadsafe so it could
work under Apache's event or worker apache mpm's.

The prefork does seem to limit somewhat the number of clients I can have
on my server, presumably due to the memory footprint (no shared code
between processes?).

It's been a while since I played with that stuff, so I've probably
forgotten some things that I should have written down "way back when" I
was developing the core website config in the early 2000's. Like,
exactly how shared is the memory for my Perl code between Apache's
preforked processes? I don't currently explicitly preload (Execute) all
of my Embperl code at startup, even though I have a switch for that in
my startup.pl, and it's been so long now (> 10 years) that I don't
remember why I disabled it. I do seem to remember that if you execute
all your files in startup.pl then it's shared at first, but then over
time that becomes more fragmented (non-shared)? Sorry to be so vague,
basically the way mod_perl/Embperl works with respect to how code gets
shared (or not) between processes has always been a bit murky to me, so
any tips would be appreciated.

Also, of course, whether event/worker is a thing I should be looking at
for Embperl at all.

Thanks!

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
richter@ecos.de wrote:
> Hi Neil,
>
> Embperl is not working with threaded mpm.
>
> Preloading all your perl code saves a lot of memory due to code sharing.
>
> The main issue is, that you have to make sure, not to open any file or database connection or similar in the preload code, because that will be shared too, which does not work

Thanks, Gerald. So, just to be clear, what my preload routine in
startup.pl does is the following. Maybe you can confirm that I'm doing
it right.

if (Apache2::ServerUtil::restart_count() == 1)
{
preload_dirs();
$Embperl::initparam{preloadfiles} = \@preload_files;
}

The preload_dirs() simply traverses my code tree and calls this for each
file:

push (@preload_files, {inputfile => $filename, path => $path, import =>
0, input_escmode => 0, options => 16, debug => 0x7fffffff});

Does that look about right? If as you say it's worthwhile in terms of
memory then I might look at re-enabling it again. I think I disabled it
originally because it made restarting the server quite slow, but it
would be useful to have it as an option should I need it.

Thanks!

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
On 06/26/2017 07:51 PM, Neil Gunton wrote:
> richter@ecos.de wrote:
>> Hi Neil,
>>
>> Embperl is not working with threaded mpm.
>>
>> Preloading all your perl code saves a lot of memory due to code sharing.
>>
>> The main issue is, that you have to make sure, not to open any file or
>> database connection or similar in the preload code, because that will
>> be shared too, which does not work
>
> Thanks, Gerald. So, just to be clear, what my preload routine in
> startup.pl does is the following. Maybe you can confirm that I'm doing
> it right.
>
> if (Apache2::ServerUtil::restart_count() == 1)
> {
> preload_dirs();
> $Embperl::initparam{preloadfiles} = \@preload_files;
> }
>
> The preload_dirs() simply traverses my code tree and calls this for each
> file:
>
> push (@preload_files, {inputfile => $filename, path => $path, import =>
> 0, input_escmode => 0, options => 16, debug => 0x7fffffff});
>
> Does that look about right? If as you say it's worthwhile in terms of
> memory then I might look at re-enabling it again. I think I disabled it
> originally because it made restarting the server quite slow, but it
> would be useful to have it as an option should I need it.
>

looks right to me although I never did this. You are just setting up
the global parameters


> Thanks!
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>


--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
Ruben Safir wrote:
> On 06/26/2017 07:51 PM, Neil Gunton wrote:
>> richter@ecos.de wrote:
>>> Hi Neil,
>>>
>>> Embperl is not working with threaded mpm.
>>>
>>> Preloading all your perl code saves a lot of memory due to code sharing.
>>>
>>> The main issue is, that you have to make sure, not to open any file or
>>> database connection or similar in the preload code, because that will
>>> be shared too, which does not work
>>
>> Thanks, Gerald. So, just to be clear, what my preload routine in
>> startup.pl does is the following. Maybe you can confirm that I'm doing
>> it right.
>>
>> if (Apache2::ServerUtil::restart_count() == 1)
>> {
>> preload_dirs();
>> $Embperl::initparam{preloadfiles} = \@preload_files;
>> }
>>
>> The preload_dirs() simply traverses my code tree and calls this for each
>> file:
>>
>> push (@preload_files, {inputfile => $filename, path => $path, import =>
>> 0, input_escmode => 0, options => 16, debug => 0x7fffffff});
>>
>> Does that look about right? If as you say it's worthwhile in terms of
>> memory then I might look at re-enabling it again. I think I disabled it
>> originally because it made restarting the server quite slow, but it
>> would be useful to have it as an option should I need it.
>>
>
> looks right to me although I never did this. You are just setting up
> the global parameters

Ok, but I'm wondering if there is something else I should be doing to
execute the actual preload. It seems that all I do here is give Embperl
an array, but when I enable the preload, it just goes through everything
suspiciously quickly. I don't think it's actually executing anything at
preload time, though I could be wrong. I'm thinking there's something
else I need to do to tell Embperl "ok, now actually load all those files"...

Neil


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
On 06/27/2017 02:21 AM, Neil Gunton wrote:
> Ok, but I'm wondering if there is something else I should be doing to
> execute the actual preload. It seems that all I do here is give Embperl
> an array, but when I enable the preload, it just goes through everything
> suspiciously quickly. I don't think it's actually executing anything at
> preload time, though I could be wrong. I'm thinking there's something
> else I need to do to tell Embperl "ok, now actually load all those
> files"...


I don't know what you are digging for here. Nor am I sure I know why
you are using preload. You can execute something when Apache starts up,
and then everything is inherited by each process, or you can load it
after it starts when each child is forked, or you can start something
when a child requests something. If you do it at the root with preload
then it is shared by everything. Your example just uses parameters that
define basic behaviors of embperl that otherwise are in the httpd.conf file.

Once loaded into memory those pages don't need to be refetched and have
a shared static footprint.

https://perl.apache.org/embperl/de/pod/doc/Config.-page-1-.htm

You started by asking if embperl is thread safe. Now what are you asking?


--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
RE: AW: Embperl and threaded mpm? [ In reply to ]
Preload isn't pre-execute. Conceptually, it's only doing roughly the work done with perl -cw. How many megabytes of pages are you actually loading that you think it would take a noticeable amount of time doing this?

The savings from preloading is a combination of being able to use more shared memory and not having to load things while the system is distracted with all the other things that need doing on starting up a new thread. And, even so, the performance gain for a single thread would be minimal, it's just notable over thousands of new thread creations. (That said, would be more noticeable for a new thread creation than a new fork creation, since forking is a more significant task.)

--
Ed Grimm
Identity Services


-----Original Message-----
From: Neil Gunton [mailto:neil@nilspace.com]
Sent: Tuesday, June 27, 2017 02:21
To: embperl@perl.apache.org
Subject: Re: AW: Embperl and threaded mpm?

Ruben Safir wrote:
> On 06/26/2017 07:51 PM, Neil Gunton wrote:
>> richter@ecos.de wrote:
>>> Hi Neil,
>>>
>>> Embperl is not working with threaded mpm.
>>>
>>> Preloading all your perl code saves a lot of memory due to code sharing.
>>>
>>> The main issue is, that you have to make sure, not to open any file or
>>> database connection or similar in the preload code, because that will
>>> be shared too, which does not work
>>
>> Thanks, Gerald. So, just to be clear, what my preload routine in
>> startup.pl does is the following. Maybe you can confirm that I'm doing
>> it right.
>>
>> if (Apache2::ServerUtil::restart_count() == 1)
>> {
>> preload_dirs();
>> $Embperl::initparam{preloadfiles} = \@preload_files;
>> }
>>
>> The preload_dirs() simply traverses my code tree and calls this for each
>> file:
>>
>> push (@preload_files, {inputfile => $filename, path => $path, import =>
>> 0, input_escmode => 0, options => 16, debug => 0x7fffffff});
>>
>> Does that look about right? If as you say it's worthwhile in terms of
>> memory then I might look at re-enabling it again. I think I disabled it
>> originally because it made restarting the server quite slow, but it
>> would be useful to have it as an option should I need it.
>>
>
> looks right to me although I never did this. You are just setting up
> the global parameters

Ok, but I'm wondering if there is something else I should be doing to
execute the actual preload. It seems that all I do here is give Embperl
an array, but when I enable the preload, it just goes through everything
suspiciously quickly. I don't think it's actually executing anything at
preload time, though I could be wrong. I'm thinking there's something
else I need to do to tell Embperl "ok, now actually load all those files"...

Neil


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
On Mon, Jun 26, 2017 at 11:21:14PM -0700, Neil Gunton wrote:
> Ruben Safir wrote:
> >On 06/26/2017 07:51 PM, Neil Gunton wrote:
> >>richter@ecos.de wrote:
> >>>Hi Neil,
> >>>
> >>>Embperl is not working with threaded mpm.
> >>>
> >>>Preloading all your perl code saves a lot of memory due to code sharing.
> >>>
> >>>The main issue is, that you have to make sure, not to open any file or
> >>>database connection or similar in the preload code, because that will
> >>>be shared too, which does not work
> >>
> >>Thanks, Gerald. So, just to be clear, what my preload routine in
> >>startup.pl does is the following. Maybe you can confirm that I'm doing
> >>it right.
> >>
> >>if (Apache2::ServerUtil::restart_count() == 1)
> >>{
> >> preload_dirs();
> >> $Embperl::initparam{preloadfiles} = \@preload_files;
> >>}


Where did you put this code?

> >>
> >>The preload_dirs() simply traverses my code tree and calls this for each
> >>file:
> >>
> >>push (@preload_files, {inputfile => $filename, path => $path, import =>
> >>0, input_escmode => 0, options => 16, debug => 0x7fffffff});
> >>
> >>Does that look about right? If as you say it's worthwhile in terms of
> >>memory then I might look at re-enabling it again. I think I disabled it
> >>originally because it made restarting the server quite slow, but it
> >>would be useful to have it as an option should I need it.
> >>
> >
> >looks right to me although I never did this. You are just setting up
> >the global parameters
>
> Ok, but I'm wondering if there is something else I should be doing
> to execute the actual preload. It seems that all I do here is give
> Embperl an array, but when I enable the preload, it just goes
> through everything suspiciously quickly. I don't think it's actually
> executing anything at preload time, though I could be wrong. I'm
> thinking there's something else I need to do to tell Embperl "ok,
> now actually load all those files"...
>
> Neil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
Ruben Safir wrote:
>>>> Thanks, Gerald. So, just to be clear, what my preload routine in
>>>> startup.pl does is the following. Maybe you can confirm that I'm doing
>>>> it right.
>>>>
>>>> if (Apache2::ServerUtil::restart_count() == 1)
>>>> {
>>>> preload_dirs();
>>>> $Embperl::initparam{preloadfiles} = \@preload_files;
>>>> }
>
>
> Where did you put this code?
>

Hi Ruben, this code goes in the BEGIN block in my startup.pl.

startup.pl is referenced in the Apache config as:

PerlRequire /path/to/startup.pl

Does that help? If not I can provide more context, but that's the
essence of it.

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl and threaded mpm? [ In reply to ]
There is a new modperl release?


On Sun, Jun 25, 2017 at 12:08:10PM -0700, Neil Gunton wrote:
> Hi all, just wondering if Embperl was ever made threadsafe so it
> could work under Apache's event or worker apache mpm's.
>
> The prefork does seem to limit somewhat the number of clients I can
> have on my server, presumably due to the memory footprint (no shared
> code between processes?).
>
> It's been a while since I played with that stuff, so I've probably
> forgotten some things that I should have written down "way back
> when" I was developing the core website config in the early 2000's.
> Like, exactly how shared is the memory for my Perl code between
> Apache's preforked processes? I don't currently explicitly preload
> (Execute) all of my Embperl code at startup, even though I have a
> switch for that in my startup.pl, and it's been so long now (> 10
> years) that I don't remember why I disabled it. I do seem to
> remember that if you execute all your files in startup.pl then it's
> shared at first, but then over time that becomes more fragmented
> (non-shared)? Sorry to be so vague, basically the way
> mod_perl/Embperl works with respect to how code gets shared (or not)
> between processes has always been a bit murky to me, so any tips
> would be appreciated.
>
> Also, of course, whether event/worker is a thing I should be looking
> at for Embperl at all.
>
> Thanks!
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
Is it a good idea to adopt this package and update it?

It wil likely die otherwise


On Mon, Jun 26, 2017 at 11:21:14PM -0700, Neil Gunton wrote:
> Ruben Safir wrote:
> >On 06/26/2017 07:51 PM, Neil Gunton wrote:
> >>richter@ecos.de wrote:
> >>>Hi Neil,
> >>>
> >>>Embperl is not working with threaded mpm.
> >>>
> >>>Preloading all your perl code saves a lot of memory due to code sharing.
> >>>
> >>>The main issue is, that you have to make sure, not to open any file or
> >>>database connection or similar in the preload code, because that will
> >>>be shared too, which does not work
> >>
> >>Thanks, Gerald. So, just to be clear, what my preload routine in
> >>startup.pl does is the following. Maybe you can confirm that I'm doing
> >>it right.
> >>
> >>if (Apache2::ServerUtil::restart_count() == 1)
> >>{
> >> preload_dirs();
> >> $Embperl::initparam{preloadfiles} = \@preload_files;
> >>}
> >>
> >>The preload_dirs() simply traverses my code tree and calls this for each
> >>file:
> >>
> >>push (@preload_files, {inputfile => $filename, path => $path, import =>
> >>0, input_escmode => 0, options => 16, debug => 0x7fffffff});
> >>
> >>Does that look about right? If as you say it's worthwhile in terms of
> >>memory then I might look at re-enabling it again. I think I disabled it
> >>originally because it made restarting the server quite slow, but it
> >>would be useful to have it as an option should I need it.
> >>
> >
> >looks right to me although I never did this. You are just setting up
> >the global parameters
>
> Ok, but I'm wondering if there is something else I should be doing
> to execute the actual preload. It seems that all I do here is give
> Embperl an array, but when I enable the preload, it just goes
> through everything suspiciously quickly. I don't think it's actually
> executing anything at preload time, though I could be wrong. I'm
> thinking there's something else I need to do to tell Embperl "ok,
> now actually load all those files"...
>
> Neil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
On 1/2/22 06:10, Ruben Safir wrote:
> Is it a good idea to adopt this package and update it?
>
> It wil likely die otherwise

I think it's pretty much "dead" anyway, at least in terms of new people
and websites using it. But then so is Perl, and even mod_perl. Hell,
even Apache is seen as passe by some people now. I still use all those,
and Sendmail, so call me a dinosaur. They work, and I have all my
configs dialed in for those tools. And I have a huge codebase (well, 20
man year's worth of work on my part for my website). So I'm going to use
Embperl for as long as I can. But I couldn't imagine using it to develop
a website for clients at this point, in good conscience. So who's using
it? I have no idea. I don't think Gerald Richter has been all that
interested in developing it for a decade or more.

If someone wanted to take it on and keep it relevant, even develop it
and expand and document all the cool features properly (I have never
used "recipes" or whatever Gerald called them) then maybe it could have
a rennaissance. I don't know. I don't have time, I have enough on my
plate just developing my own stuff.

People like to work on new stuff. Even on established open source
projects, you see people doing total rewrites every so often, just (I
guess) because it's easier to work on new code than maintain old. It's
an old story. I'm going through this right now with Thunderbird - 91.x
seems to be a lot of new code, because stuff that used to just work, now
doesn't. That's the downside to rewrites - all those years of
accumulated coding wisdom, little tweaks, down the drain.

So I'd hope that if anyone does take on Embperl, they won't rewrite from
scratch. Perl 6 is another example. It basically killed Perl, because
everybody was eternally waiting for Perl 6, which made Perl 5 look
passe, and eventually everybody just stopped waiting and used PHP or
Ruby or Python or whatever. The Perl devs really screwed the pooch on
Perl 6, in my opinion as a peripheral observer and developer. I don't
really care how cool the language is. If it's not a smooth and seamless
transition from Perl 5 to Perl 6, then it's useless to me. I don't care
about cool language features, I just want to get stuff done, and not
break all the code I have accumulated over the last 20 years.

Embperl is still great. But increasingly I find I use real Perl subs
rather than the [$ sub $], due to the better handling of local
variables. Most of the big bugs I've had have been due to leaking
variables across different Embperl subs. So now I only try to use those
for very basic stuff. If it's at all complex, then I convert that code
to a Perl sub, inside [- -], not [$ sub $]. The feature that I really
like about Embperl is the object oriented directory structure, which
lets you redefine files and subs in sub folders. I may be wrong, but it
really works for me and I like it. That's the big thing I wouldn't want
to give up if I had to move away from Embperl, really - the folder-based
hierarchy of subroutine overriding. Maybe there's clever ways to get the
same effect by other means, I'm sure there are, but Embperl still "just
works", it's stable so I hope it continues to work for a long while yet.

I don't know if Gerald is still out there reading these emails, but if
he is - THANK YOU. You gave us an awesome tool, and I hope if I ever get
my business successful one way then I'll be able to repay you somehow.

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: AW: Embperl and threaded mpm? [ In reply to ]
It seems to have been adopted and is being actively maintained
"downstream."

https://tracker.debian.org/pkg/libembperl-perl

On Sun, Jan 2, 2022 at 6:10 AM Ruben Safir <ruben@mrbrklyn.com> wrote:

> Is it a good idea to adopt this package and update it?
>
> It wil likely die otherwise
>
>
> On Mon, Jun 26, 2017 at 11:21:14PM -0700, Neil Gunton wrote:
> > Ruben Safir wrote:
> > >On 06/26/2017 07:51 PM, Neil Gunton wrote:
> > >>richter@ecos.de wrote:
> > >>>Hi Neil,
> > >>>
> > >>>Embperl is not working with threaded mpm.
> > >>>
> > >>>Preloading all your perl code saves a lot of memory due to code
> sharing.
> > >>>
> > >>>The main issue is, that you have to make sure, not to open any file or
> > >>>database connection or similar in the preload code, because that will
> > >>>be shared too, which does not work
> > >>
> > >>Thanks, Gerald. So, just to be clear, what my preload routine in
> > >>startup.pl does is the following. Maybe you can confirm that I'm doing
> > >>it right.
> > >>
> > >>if (Apache2::ServerUtil::restart_count() == 1)
> > >>{
> > >> preload_dirs();
> > >> $Embperl::initparam{preloadfiles} = \@preload_files;
> > >>}
> > >>
> > >>The preload_dirs() simply traverses my code tree and calls this for
> each
> > >>file:
> > >>
> > >>push (@preload_files, {inputfile => $filename, path => $path, import =>
> > >>0, input_escmode => 0, options => 16, debug => 0x7fffffff});
> > >>
> > >>Does that look about right? If as you say it's worthwhile in terms of
> > >>memory then I might look at re-enabling it again. I think I disabled it
> > >>originally because it made restarting the server quite slow, but it
> > >>would be useful to have it as an option should I need it.
> > >>
> > >
> > >looks right to me although I never did this. You are just setting up
> > >the global parameters
> >
> > Ok, but I'm wondering if there is something else I should be doing
> > to execute the actual preload. It seems that all I do here is give
> > Embperl an array, but when I enable the preload, it just goes
> > through everything suspiciously quickly. I don't think it's actually
> > executing anything at preload time, though I could be wrong. I'm
> > thinking there's something else I need to do to tell Embperl "ok,
> > now actually load all those files"...
> >
> > Neil
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
>
> --
> So many immigrant groups have swept through our town
> that Brooklyn, like Atlantis, reaches mythological
> proportions in the mind of the world - RI Safir 1998
> http://www.mrbrklyn.com
>
> DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
> http://www.nylxs.com - Leadership Development in Free Software
> http://www2.mrbrklyn.com/resources - Unpublished Archive
> http://www.coinhangout.com - coins!
> http://www.brooklyn-living.com
>
> Being so tracked is for FARM ANIMALS and extermination camps,
> but incompatible with living as a free human being. -RI Safir 2013
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>