You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/12/04 07:33:42 UTC

PerlIO::APR: getting the memory pool

I'm implementing PerlIO::APR (will be APR::IO in mod_perl)

I need to get my hands on the memory pool. Currently I use the global 
pool via modperl_global_get_pconf(). which allows you to keep your code 
as a pure perl:

open my $fh, ">:APR", $path or die "$!";

Does calling modperl_global_get_pconf() make things slower? If it does, 
where do we stick $r/$s? something like this?

($r||$s)->file_open(my $fh, ">", $path) or die $!;?

or may be we can keep the perl syntax and use the server pool? which can 
be fetched only once and stored in a static variable? In fact we can do 
the same with modperl_global_get_pconf(),

but I think there is a problem if we don't use $r's pool -- the memory 
allocated during file ops won't be cleaned at the end of request :( but 
I really want to keep the perl syntax, so how about this:

open my $fh, ">:APR", $r, $path or die "$!";

or:

open my $fh, ">:APR", $path, $r or die "$!";

s/$r/$s/ will work too.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


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


Re: PerlIO::APR: getting the memory pool

Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 6 Dec 2001, Stas Bekman wrote:
 
> While we are at it. I've placed the implementation into 
> modperl_perlio.c|h and xs/APR/IO/APR_IO.h. Is that OK?

should be: xs/APR/PerlIO/APR__PerlIO.h
 
> yes, there is, but the problem is translating errno from APR to Perl's 
> errno. Perl's SETERRNO accepts special predefined errcode

those are just constants.  you can do this:
SETERRNO(errno_pulled_out_of_apr_status_t, 0);

we can worry about the vms code later if modperl ever happens to be ported
to that platform.




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


Re: PerlIO::APR: getting the memory pool

Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:

> On Thu, 6 Dec 2001, Stas Bekman wrote:
> 
> 
>>but I guess I don't understand something: why do we need to use 
>>APR::File->open? What's wrong with perl's open()? I've it working 
>>already.  If you don't use perl's open() do you also imply that we have 
>>to use $fh->close, $fh->seek and so on, using APR arguments? What's the 
>>point of having PerlIO layer at all?
>>
> 
> my interest in having an APR::File->open() was so we can pass in the
> args directly rather than jump through hoops to convert the perl sugar.
> it would end up calling apr_file_open exactly the same way the builtin
> open would.  but then again, you are implementing APR::PerlIO/PerlIO::APR
> not APR::File, so forget APR::File->open.


great!

While we are at it. I've placed the implementation into 
modperl_perlio.c|h and xs/APR/IO/APR_IO.h. Is that OK?



>>so the only thing it misses is $r|$s, which can be:
>>
>>   open my $fh, $r, ...
>>
> 
> that should be easy with modperl_sv2pool, right?


yup

 
>>I'm not sure how to handle the best the forwarding of any errors from 
>>APR's side to Perl side. I don't think it's possible to convert APR's 
>>errno into Perl's errno, without a *lot* of hassle. what's the best way 
>>to go?
>>
> 
> there is something in apr to get the errno out of apr_status_t,
> don't remember what it is though.


yes, there is, but the problem is translating errno from APR to Perl's 
errno. Perl's SETERRNO accepts special predefined errcode

perl-current/perl.h:#   define SETERRNO(errcode,vmserrcode) (errno = 
(errcode))

I guess I'll post soon the working protototype without handling the 
errors and then we will see what's the best way to handle the errors.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


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


Re: PerlIO::APR: getting the memory pool

Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 6 Dec 2001, Stas Bekman wrote:

> but I guess I don't understand something: why do we need to use 
> APR::File->open? What's wrong with perl's open()? I've it working 
> already.  If you don't use perl's open() do you also imply that we have 
> to use $fh->close, $fh->seek and so on, using APR arguments? What's the 
> point of having PerlIO layer at all?

my interest in having an APR::File->open() was so we can pass in the
args directly rather than jump through hoops to convert the perl sugar.
it would end up calling apr_file_open exactly the same way the builtin
open would.  but then again, you are implementing APR::PerlIO/PerlIO::APR
not APR::File, so forget APR::File->open.
 
> I've basic tests working using a pure perl syntax and apr calls as its 
> internals. Here is a snippet from the test:
> 
>          open my $fh, "<:APR", $file
>              or die "Cannot open $file for reading: $!";
> 
>          open my $dup_fh, "<&:APR", $fh
>              or die "Cannot dup $file for reading: $!";
>          close $fh;
> 
>          my $received = <$dup_fh>;
>          close $dup_fh;

cool.
 
> so the only thing it misses is $r|$s, which can be:
> 
>    open my $fh, $r, ...

that should be easy with modperl_sv2pool, right?

> I'm not sure how to handle the best the forwarding of any errors from 
> APR's side to Perl side. I don't think it's possible to convert APR's 
> errno into Perl's errno, without a *lot* of hassle. what's the best way 
> to go?

there is something in apr to get the errno out of apr_status_t,
don't remember what it is though.


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


Re: PerlIO::APR: getting the memory pool

Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:

> On Tue, 4 Dec 2001, Stas Bekman wrote:
> 
> 
>>I'm implementing PerlIO::APR (will be APR::IO in mod_perl)
>>
>>I need to get my hands on the memory pool. Currently I use the global 
>>pool via modperl_global_get_pconf(). which allows you to keep your code 
>>as a pure perl:
>>
>>open my $fh, ">:APR", $path or die "$!";
>>
>>Does calling modperl_global_get_pconf() make things slower? If it does, 
>>where do we stick $r/$s? something like this?
>>
> 
> you can use the modperl_sv2pool() function, see the
> ap_server_root_relative() wrapper for an example.
> 
> or just force an APR::Pool argument to be passed.  using the perl builtin
> open is just sugar, there should be an APR::File->open function that takes
> the same args as apr_file_open().

So should the open syntax be something like this:

my $fh = APR::File->open($r|$s, <apr_file_open args>) or die $!;

but I guess I don't understand something: why do we need to use 
APR::File->open? What's wrong with perl's open()? I've it working 
already.  If you don't use perl's open() do you also imply that we have 
to use $fh->close, $fh->seek and so on, using APR arguments? What's the 
point of having PerlIO layer at all?

I've basic tests working using a pure perl syntax and apr calls as its 
internals. Here is a snippet from the test:

         open my $fh, "<:APR", $file
             or die "Cannot open $file for reading: $!";

         open my $dup_fh, "<&:APR", $fh
             or die "Cannot dup $file for reading: $!";
         close $fh;

         my $received = <$dup_fh>;
         close $dup_fh;

so the only thing it misses is $r|$s, which can be:

   open my $fh, $r, ...

I'm not sure how to handle the best the forwarding of any errors from 
APR's side to Perl side. I don't think it's possible to convert APR's 
errno into Perl's errno, without a *lot* of hassle. what's the best way 
to go?

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


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


Re: PerlIO::APR: getting the memory pool

Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 4 Dec 2001, Stas Bekman wrote:

> I'm implementing PerlIO::APR (will be APR::IO in mod_perl)
> 
> I need to get my hands on the memory pool. Currently I use the global 
> pool via modperl_global_get_pconf(). which allows you to keep your code 
> as a pure perl:
> 
> open my $fh, ">:APR", $path or die "$!";
> 
> Does calling modperl_global_get_pconf() make things slower? If it does, 
> where do we stick $r/$s? something like this?

you can use the modperl_sv2pool() function, see the
ap_server_root_relative() wrapper for an example.

or just force an APR::Pool argument to be passed.  using the perl builtin
open is just sugar, there should be an APR::File->open function that takes
the same args as apr_file_open().




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