Re: Serious performance bug in Perl
"Darren/Torin/Who Ever..." <torin@daft.com> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Daniel Martin, in an immanent manifestation of deity, wrote:
> >My... it's been a while since I was investigating perl internals
> >(writing C code that was callable from perl) - at least two years,
> >which somehow seems much longer.
> >
> >Well, I'll have my machine download the perl source tonight and see
> >what I can see...
>
> Thanks for taking a look at this. I won't have time to do so until
> Tuesday; it being Solstice Weekend and all.
>
> Darren
Ok, I've looked at it.
I really don't know quite what to do with this. On the one hand,
automatically reading the shadow password entries is desireable since
it keeps old scripts working without knowing whether shadow passwords
are being used or not. On the other hand, doing a getspnam for every
getpw* call causes serious performance issues.
The solution, as I said before, seems to be invoking some kind of
magic on the scalar that's second in the list returned by getpw*.
(what traditionally is the encrypted password field)
Here's the problem:
Perl has various kinds of builtin magics, but all of them do highly
specialized things, such that adding a new kind of builtin magic
necessitates changes in several different places, and any new "shadow
password entry" magic type might be incompatible with future versions
of perl. Now there are two types of magic reserved for use by
extensions, but I'm loathe to use them since it's hard to avoid name
conflicts with those magics; also, changing getpw* mucks with perl's
internal code and the docs seem to suggest that internal perl
procedures shouldn't use those types of magics. (Admittedly, a bit of
"U"-type magic might serve as a temporary fix, and may be the best
(read: most easily implemented) solution at the moment)
Now, add to that the fact that it wouldn't be all that hard to write a
perl module (called, say, "ShadowPasswd") that would provide
replacement getpw* functions (yes, one can replace perl builtin
functions with ones from modules), as well as proper getsp* functions,
and could handle the magic nicely so that getspnam isn't called
unnecessarily through a tied scalar. (I am aware of the "Shadow"
module written for 5.003 that provides some small interface to getsp*
- this would do more) This really seems the cleanest solution, and
may indeed be easier to implement than the U-magic method. (Note that
with this, it would even be possible to create a shadow-aware
setpwent; I still need to think out the details and implications of
that, though)
The only problem now is that scripts would have to say "use
ShadowPasswd;" or they wouldn't have shadow password support - this
could potentially break many scripts. So, some might say that the
solution is to have getpw* autoload the ShadowPasswd module; if I
could figure out how to do this, I'd say that this is the solution we
should shoot for. Unfortunately, I got lost somewhere in the perl
source code and couldn't find my way to how that might be done.
Also, is the Cc: list on this mail too broad? Should someone else be
getting these messages too? Should this be taken off debian-devel?
DANIEL
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: