apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r368769 - /apr/apr/trunk/include/apr_file_io.h
Date Fri, 13 Jan 2006 20:31:58 GMT
Mladen Turk wrote:
> 
> The question is if they'll be ever used, or particularly,
> can someone write the implementation without using pool.

Contrawise, can someone write a better implementation, if given a pool?

> Since the return value from those functions is int, I'm
> almost sure they could be, by using stack for temp storage,

Huh?  How does the rv pertain to the implementation?

But on the issue of temp storage, win32 is VERY stack-heavy right now.
We all know stack is the least safe location to manipulate arrays.  Although
I trust (and trust that others have vetted) my utf8/ucs2 implementation, that
does not mean we shouldn't consider moving these hefty strings outside of the
stack, into a pool-based apr-specific filename cache or two (two, because some
ops like rename will require origin/destination pragmas).

If I did this, we would have to also point out that the pool passed to these
functions must be per-thread pools, or they could collide.  So it's not an
optimization I'd make until APR 2.

> and further more since no additional object is created that would
> require cleanup.

As others point out, Win32 is and isn't unique.  You destroy the ability for
authors of other obscure platforms to port apr when you clip their options
out from under them.  APR isn't 'done'.  At least, we hope it's not :)

> I think they were simply over engineered initially.

Again, perhaps, but the cost of passing a pool reference isn't measureable
against calling the filesystem to perform disk magic.

Bill

Mime
View raw message