Re: Serious performance bug in Perl
As the proud owner of that particular patch, I guess I should say
something... :)
>>>>> "Daniel" == Daniel Martin at cush <dtm12@jhunix.hcf.jhu.edu> writes:
Daniel> Ok, I've looked at it.
Daniel> I really don't know quite what to do with this. On the
Daniel> one hand, automatically reading the shadow password
Daniel> entries is desireable since it keeps old scripts working
Daniel> without knowing whether shadow passwords are being used or
Daniel> not. On the other hand, doing a getspnam for every getpw*
Daniel> call causes serious performance issues.
When I wrote the patch, I didn't have a 3000 entry /etc/passwd so was
unaware of any major performance issue with getspnam.
Daniel> The solution, as I said before, seems to be invoking some
Daniel> kind of magic on the scalar that's second in the list
Daniel> returned by getpw*. (what traditionally is the encrypted
Daniel> password field)
This, IMHO, is overkill. A less intrusive solution may be to do an
setspent call in the setpwent code within p_sys.c. Unfortunately, my
getspent man page seems to have gone missing so I can't check on the
feasiblity of this solution right now.
Daniel> Here's the problem: Perl has various kinds of builtin
Daniel> magics, but all of them do highly specialized things, such
Daniel> that adding a new kind of builtin magic necessitates
Daniel> changes in several different places, and any new "shadow
Daniel> password entry" magic type might be incompatible with
Daniel> future versions of perl. Now there are two types of magic
Daniel> reserved for use by extensions, but I'm loathe to use them
Daniel> since it's hard to avoid name conflicts with those magics;
Daniel> also, changing getpw* mucks with perl's internal code and
Daniel> the docs seem to suggest that internal perl procedures
Daniel> shouldn't use those types of magics. (Admittedly, a bit
Daniel> of "U"-type magic might serve as a temporary fix, and may
Daniel> be the best (read: most easily implemented) solution at
Daniel> the moment)
If you wanted to go that route it would make more sense to do a hidden
tie on the pw scalar and use that to control the lookup. The you'd
just have to find an appropriate namespace for such a beast.
Daniel> Also, is the Cc: list on this mail too broad? Should
Daniel> someone else be getting these messages too? Should this
Daniel> be taken off debian-devel?
It should, in fact, be on the p5p list.
--
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes... - Gregory R Block
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: