You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Adam Kennedy <ad...@phase-n.com> on 2004/12/30 04:13:11 UTC
[Fwd: Some questions about mod_perl 2.0]
Hi guys
I'm just reading through the docs of the new mod_perl and I had a couple
of questions. (and maybe issues).
Perl/CPAN Tool Chain
--------------------
I'm just finishing up PPI.pm at the moment on a Perl Foundation grant,
and I know a lot of perl tool chain modules (autodocumentation,
dependency checking, API detection, autodocumentation, PAR, etc etc) are
likely to end up using it in some form or another...
I'm wondering how you plan to make the modifications to the various
modules that might be effected by this new concept of "two different
modules (APIs) with the same name"
Are you going to be taking over CPAN.pm and CPANPLUS.pm, or contributing
patches to make it handle it?
How will you tell what to install when someone does
perl -MCPAN -e 'install My::Module'
How will you know that a) It is an Apache2-related module and b) which
version to install?
Do you have a patch yet for modifying the PAUSE indexer to handle this?
I'm also little worried about dependency-scanning tools too.
At the moment when I give a bit of code to a dependency scanner, it
finds the string 'use Foo::Bar;' in my source and knows I have a
Foo::Bar module dependency, whether or not it has that module installed
itself.
If you are going to have multiple modules with the same name, how do you
plan on resolving this?
Also, dependency logic and config data throughout all of CPAN and the
entire perl/CPAN tool chain is currently listed in "Foo::Bar 1.23" form,
where it takes any version of Foo::Bar higher than 1.23.
It would seem that the entire tool chain is also going to need to be
moved to use something like only.pm, where the dependency is done as a
complex expression... is this right?
If I want to uniquely identify one of an arbitrary number of APIs within
a single namespace, for example to make a database key in my tool that
parsers all of CPAN to find bugs in the PPI lexer, what should I use?
Threads
-------
My second question is related to the thread-safe'ness issue.
Some of the docs say that everything is going to need to be thread-safe
now. Does this mean I can only include CPAN modules if they are thread-safe?
If so, do you have a solution for detecting if any arbitrary code or
module is thread-safe or not?
There are 14 million lines of perl in CPAN, are we going to have to
rewrite all of them to make them thread-safe before we can use any of
them with mod_perl 2.0? We have enough problems maintaining some of them
already...
I would imagine that many modules can't be made thread-safe without
fundamentally changing their APIs as well... do you see a risk of API
cascade here, where a significant percentage of the 8,000 CPAN packages
have to be rewritten to be able to use them in mod_perl?
Making the "Multiple APIs per Package" Decision
------------------------------------------------------
Finally, a general question. I'm wondering why you chose to keep the
same namespace for a totally different API, instead of moving to Apache2
like some other modules like the SQLite modules have done (to SQLite2
and SQLite3) when their APIs needed to change to match a new underlying
API. I'm not aware of any other cases that did something like this other
than GD, and that has frankly been a total disaster. It generates
something like 90% of my support requests even to this day, despite
being only one small support module of a secondary project of mine (CVS
Monitor).
The use of GD has been abandoned in many cases (I would have done so if
I had the time to do it) simply because, for several years, it's been
near impossible for any user to install it successfully.
Is the decision process that led you to choose to keep the same
namespace documented somewhere so I can understand a bit easier, or was
it an arbitrary decision?
My immediate thoughts are that if (for the most part) all modules need
to be rewritten or changed in order to work with Apache 2, that would
seem to fit quite well with Apache2:: as you would add a re-written
version for each of the hundred or so Apache-related modules as
Apache2::XXXX instead of Apache::XXXX.
This would leave Apache 1 users with a support legacy version, and newer
projects can move to using Apache2:: at a pace that suits them.
It would also mean you could have alternative authors much more
easily... For many CPAN modules the original authors may not even be
around any more (see the File::Remove Changes file for an example).
How are you planning on allowing the CPAN indexer to support multiple
APIs by different authors occupying the same namespace at the same time?
Thanks in advance for your assistance
Adam Kennedy
http://search.cpan.org/~adamk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Stas Bekman <st...@stason.org>.
Adam Kennedy wrote:
>> If a module has XS code and doesn't provide a CLONE function, most
>> likely it is not thread-safe (you can grep for CLONE). Of course those
>> that provide the CLONE function aren't necessarily completely
>> thread-safe. e.g. I've added CLONE only for the top level class in
>> GTop, the rest of classes in that package are still not thread-safe.
>> It's possible that XS module will be thread-safe w/o CLONE, it depends
>> on what it does.
>
>
> While this may be true, a comparatively small number of modules use XS.
>
> In fact, if you like I can get hard numbers on that, as I'm writing some
> module-scanning tasks at the moment and a check for the use of bootstrap
> would probably make a nice test.
>
> There are a lot of other issues at a perl level. Such as any feature
> implemented with the temporary localisation of globals.
I certainly didn't say that it was *the* test. Just something to consider.
The other thread-"safety" issues include:
http://perl.apache.org/docs/2.0/user/coding/coding.html#Thread_environment_Issues
> When you summarise the response, I would definitely appreciate a section
> on how we address and manage multiple-active-APIs-per-namespace at a
> CPAN-wide level, since that it would appear that feature is needed to
> make this mod_perl 2 idea work.
that's the main chunk of the summary.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> =item * Distributors
>
> Distributors should mark the different generations of mod_perl as
> conflicting, so only one version can be installed using the binary
> package. Users requiring more than one installation should do a manual
> install.
+1
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman said:
> The thing is: 99.9% of users need to have only one modperl generation,
> therefore I think the conflicting marking is the preferrable approach. But
> I could be wrong.
I'm not sure they actually mark them as conflicting, but they do seem to
be coping with this so far, since Red Hat switched to apache 2 years ago
and has been shipping mod_perl 2 since then, and "libapache2-mod-perl2" is
the recommended mod_perl package on my (Debian-based) Ubuntu system.
Moreover, they make mod_perl packages depend on one or the other apache
package. Fedora 3 doesn't even have official apache 1 packages.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Stas Bekman <st...@stason.org>.
Adam Kennedy wrote:
>>>> =item * Distributors
>>>>
>>>> Distributors should mark the different generations of mod_perl as
>>>> conflicting, so only one version can be installed using the binary
>>>> package. Users requiring more than one installation should do a manual
>>>> install.
>>> So I presume this would apply to all of Apache-related CPAN modules
>>> as well?
>>>
>>> Wouldn't this mean that people like debian are going to have
>>>
>>> libapache-module-perl and libapache2-module-perl and have them marked
>>> as conflicting?
In order to have any of the packages installed they need to have the
correct modperl package installed. So there is no need to mark the 3rd
party modules as conflicting, since their most important prerequisite (the
modperl-core) is already handling that.
But again, this is just an idea so far. If I were the packager I'd do
that. Of course real packagers can decide to use this suggestion or build
all mp2 core and 3rd party modules into Apache2/ subdir, in which case the
two will always co-exist.
The thing is: 99.9% of users need to have only one modperl generation,
therefore I think the conflicting marking is the preferrable approach. But
I could be wrong.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Adam Kennedy <ad...@phase-n.com>.
Stas Bekman wrote:
> Mind to post this to the list? It's an important issue, that was just an
> idea I wrote last night.
>
> Adam Kennedy wrote:
>
>> (off-list)
>>
>> So I presume this would apply to all of Apache-related CPAN modules as
>> well?
>>
>> Wouldn't this mean that people like debian are going to have
>>
>> libapache-module-perl and libapache2-module-perl and have them marked
>> as conflicting?
>>
>> Anyways, I'll let you get back to the summary and I'll comment
>> directly off that if you prefer
>>
>> Adam
>>
>>> =item * Distributors
>>>
>>> Distributors should mark the different generations of mod_perl as
>>> conflicting, so only one version can be installed using the binary
>>> package. Users requiring more than one installation should do a manual
>>> install.
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Adam Kennedy said:
>
>>While I'm thinking about it, has anyone talked to Red Hat or the Debian
>>people to see how the separate distribution of identically named module
>>will work within all of the distro's various packaging systems?
>
>
> Doesn't seem like a problem to me since a) they just ship the mod_perl
> that goes with the apache version they choose to ship and b) their package
> systems work fine with anything that doesn't have overlapping files, and
> the current mp2 plan has no overlapping files.
what about manpages? Those do overlap. Or may be they don't install those?
In any case, this is not a problem, since any system that has more than
one generation, which doesn't change the API (take BerkleyDB for example,
but it's true for 99.9% of C projects) can have only one set of manpages.
I think we should advise packagers (this is from my summary-in-progress):
=item * Distributors
Distributors should mark the different generations of mod_perl as
conflicting, so only one version can be installed using the binary
package. Users requiring more than one installation should do a manual
install.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Adam Kennedy <ad...@phase-n.com>.
Perrin Harkins wrote:
> Adam Kennedy said:
>
>>While I'm thinking about it, has anyone talked to Red Hat or the Debian
>>people to see how the separate distribution of identically named module
>>will work within all of the distro's various packaging systems?
>
>
> Doesn't seem like a problem to me since a) they just ship the mod_perl
> that goes with the apache version they choose to ship and b) their package
> systems work fine with anything that doesn't have overlapping files, and
> the current mp2 plan has no overlapping files.
Well, a) many ship both versions of apache, which means both versions of
mod_perl and b) In debian's case, while the files themselves may be
different there is a standard method for determining the debian package
name for any given perl module name that assumes that the module names
are unique, so I presume that we'll need a change to the debian package
naming "algorithm" (for some use of the word) for perl modules.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Perrin Harkins <pe...@elem.com>.
Adam Kennedy said:
> While I'm thinking about it, has anyone talked to Red Hat or the Debian
> people to see how the separate distribution of identically named module
> will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they just ship the mod_perl
that goes with the apache version they choose to ship and b) their package
systems work fine with anything that doesn't have overlapping files, and
the current mp2 plan has no overlapping files.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Adam Kennedy <ad...@phase-n.com>.
> If a module has XS code and doesn't provide a CLONE function, most
> likely it is not thread-safe (you can grep for CLONE). Of course those
> that provide the CLONE function aren't necessarily completely
> thread-safe. e.g. I've added CLONE only for the top level class in GTop,
> the rest of classes in that package are still not thread-safe. It's
> possible that XS module will be thread-safe w/o CLONE, it depends on
> what it does.
While this may be true, a comparatively small number of modules use XS.
In fact, if you like I can get hard numbers on that, as I'm writing some
module-scanning tasks at the moment and a check for the use of bootstrap
would probably make a nice test.
There are a lot of other issues at a perl level. Such as any feature
implemented with the temporary localisation of globals.
When you summarise the response, I would definitely appreciate a section
on how we address and manage multiple-active-APIs-per-namespace at a
CPAN-wide level, since that it would appear that feature is needed to
make this mod_perl 2 idea work.
While I'm thinking about it, has anyone talked to Red Hat or the Debian
people to see how the separate distribution of identically named module
will work within all of the distro's various packaging systems?
(just something to add to the pot)
Thanks again
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Adam Kennedy said:
>
>>I'm wondering how you plan to make the modifications to the various
>>modules that might be effected by this new concept of "two different
>>modules (APIs) with the same name"
>
>
> Adam, this is under heavy discussion right now and is not really resolved.
> There is no solution that solves every problem at the moment. Please
> stand by for further developments on this.
The discussion is about various workarounds. Regardless the mp2 API stays
as it is now.
I'll post a summary of the discussion so far when I'm done with it.
>>If so, do you have a solution for detecting if any arbitrary code or
>>module is thread-safe or not?
>
> This would be a general perl thing, not a mod_perl thing. I'm not aware
> of any automatic scanning utility for this.
If a module has XS code and doesn't provide a CLONE function, most likely
it is not thread-safe (you can grep for CLONE). Of course those that
provide the CLONE function aren't necessarily completely thread-safe. e.g.
I've added CLONE only for the top level class in GTop, the rest of classes
in that package are still not thread-safe. It's possible that XS module
will be thread-safe w/o CLONE, it depends on what it does.
for more information see the docs in:
http://apache.org/~stas/Example-CLONE-0.02.tar.gz
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Some questions about mod_perl 2.0]
Posted by Perrin Harkins <pe...@elem.com>.
Adam Kennedy said:
> I'm wondering how you plan to make the modifications to the various
> modules that might be effected by this new concept of "two different
> modules (APIs) with the same name"
Adam, this is under heavy discussion right now and is not really resolved.
There is no solution that solves every problem at the moment. Please
stand by for further developments on this.
> Some of the docs say that everything is going to need to be thread-safe
> now. Does this mean I can only include CPAN modules if they are
> thread-safe?
If you are running with threads, yes. At the moment, running the prefork
MPM is preferred on platforms that support it. Win32 only supports
threads though.
> If so, do you have a solution for detecting if any arbitrary code or
> module is thread-safe or not?
This would be a general perl thing, not a mod_perl thing. I'm not aware
of any automatic scanning utility for this.
> There are 14 million lines of perl in CPAN, are we going to have to
> rewrite all of them to make them thread-safe before we can use any of
> them with mod_perl 2.0?
If you want to run them with threads, then yes, they will need to be
thread-safe. Don't run threads if you are not sure about the safety of
the modules you want to use.
> I would imagine that many modules can't be made thread-safe without
> fundamentally changing their APIs as well...
That seems unlikely to me. There was an example early on of how even very
unsafe APIs like Cwd can be preserved if people care to.
> Finally, a general question. I'm wondering why you chose to keep the
> same namespace for a totally different API, instead of moving to Apache2
> like some other modules like the SQLite modules have done (to SQLite2
> and SQLite3) when their APIs needed to change to match a new underlying
> API.
On the mod_perl users list, Stas and Joe Schaefer were just explaining
some of the problems with the name-changing approach to me. You may want
to read some of that thread:
http://marc.theaimsgroup.com/?l=apache-modperl&m=110428695916016&w=2
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org