dev,ino namespace [was: Re: Apache::Registry - a thought]

[Ime Smits]

| It occurs to me that there would be no overhead to speak of in using a
| sequence number, given that Apache::Registry already maintains a hash for
| its generated package names for mtime checks. Something like:

Why not use (stat($script))[0,1] device and inode numbers of the script
being compiled? It has the advantage of code-sharing symlinked scripts - but
probably can only be used on Unix like flavours.

I got tremendous improvements in my situation where I have quite some
domains basically running the same huge stuff with some minor layout
adjustments based on HTTP Host header.

As I use Apache::ASP a lot, I have some (fairly trivial) patches submitted
for this feature to Joshua, who will probably include them in the next
release. I think it would be nice for Apache::Registry to have this feature
as well.

Anyone interested in the Apache::ASP patches, just drop me line.

Ime

Re: Apache::Registry - a thought

[Matt Sergeant]

On Mon, 30 Apr 2001, Pete Jordan wrote:

> I've been off this list for over a year, so I may be covering ground that 
> I've failed to find in the archives, but whatever...
> 
> I've had occasion to examine the internals of Apache::Registry recently[1] 
> and have been reminded of the unfeasably long package names that it 
> generates for scripts.
> 
> It occurs to me that there would be no overhead to speak of in using a 
> sequence number, given that Apache::Registry already maintains a hash for 
> its generated package names for mtime checks. Something like:
> 
>   my $script=
> $Apache::Registry->{$script_name}||=
>   {seq => ++$Apache::Registry::seq, mtime => $mtime+1};
> 
>   my $package=sprintf "Apache::MAIN::S%04d", $script->{seq};
> 
>   $r->log_error("Apache::Registry::handler package $package")
>  if $Debug && $Debug & 4;
> 
>   $r->chdir_file;
> 
>   unless ($script->{mtime} <= $mtime) {
> $script->{mtime}=$mtime;
> $package=sprintf "Apache::MAIN::S%04d", $script->{seq};
> 
> # compile into $package
>   }
> 
>   my $old_status = $r->status;
> 
>   my $cv = \&{"$package\::handler"};
>   eval { &{$cv}($r, @_) } if $r->seqno;
> 
>   # and so on...

This would be trivial to do. Just implement a package derived from
Apache::RegistryNG (e.g. Apache::MyRegistry) that implements a single
method namespace().

-- 


/||** Founder and CTO  **  **   http://axkit.com/ **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
 \\//
 //\\
//  \\

Re: Apache::Registry - a thought

[Pete Jordan]

Oh ghod, what have I started... :)

I promise not to add footnotes to my messages in future...

/Pete/ 

Apache::Registry - a thought

[Pete Jordan]

I've been off this list for over a year, so I may be covering ground that 
I've failed to find in the archives, but whatever...

I've had occasion to examine the internals of Apache::Registry recently[1] 
and have been reminded of the unfeasably long package names that it 
generates for scripts.

It occurs to me that there would be no overhead to speak of in using a 
sequence number, given that Apache::Registry already maintains a hash for 
its generated package names for mtime checks. Something like:

my $script=
  $Apache::Registry->{$script_name}||=
{seq => ++$Apache::Registry::seq, mtime => $mtime+1};

my $package=sprintf "Apache::MAIN::S%04d", $script->{seq};

$r->log_error("Apache::Registry::handler package $package")
   if $Debug && $Debug & 4;

$r->chdir_file;

unless ($script->{mtime} <= $mtime) {
  $script->{mtime}=$mtime;
  $package=sprintf "Apache::MAIN::S%04d", $script->{seq};

  # compile into $package
}

my $old_status = $r->status;

my $cv = \&{"$package\::handler"};
eval { &{$cv}($r, @_) } if $r->seqno;

# and so on...

Seems a lot clearer to me than what we now have (particularly if a script 
directory is way down the directory hierarchy), gets round the need for 
name mangling, and the real script name is still there in the file field 
of stack frames for diagnostic purposes.

Pete Jordan

[1] for my Perl exception package (yes, another one :) which, in its 
development version, now mostly does the Right Thing for mod_perl. See 
http://sourceforge.net/projects/perlexception/ for the curious.