On Thu, 2008-10-02 at 23:40 -0700, Tim Bray wrote:
> status = apr_file_open(&fp, tempname, APR_FOPEN_WRITE |
> APR_FOPEN_CREATE, PERMS, pool);
Where does the tempname come from?
--
Bojan
I'm developing a module which accepts a large number of POST requests,
receives the request bodies, and persists them into ordinary files in
the filesystem. On OS X, there are occasions where the file is
(rarely) transiently not there. The idiom looks like this
status = apr_file_open(
On Oct 2, 2008, at 8:11 PM, Paul Querna wrote:
Tim Bray wrote:
I stupidly used random() and srandom() in my module to generate
"random" filenames at high volume and, well, sigh. Anyhow, the
page at http://apr.apache.org/docs/apr/1.3/group__apr__random.html
lacks tutorial value. Anyone w
On Thu, 2008-10-02 at 21:08 -0700, peter baer wrote:
> Also, if you look at the apr_reslist_create() documentation, it states
> that the ttl "if non-zero, sets the maximum amount of time a resource
> may be available while exceeding the soft limit. ". Why then is the
> destructor being called for
Hi Bojan,
First, I'd like to say thank you for the quick response. The ttl is in
fact in microseconds. The documentation seems to be incorrect:
apr_memcache_server_create() ttl - time to live in seconds of a client
connection.
Also, if you look at the apr_reslist_create() documentation, it states
Tim Bray wrote:
I stupidly used random() and srandom() in my module to generate "random"
filenames at high volume and, well, sigh. Anyhow, the page at
http://apr.apache.org/docs/apr/1.3/group__apr__random.html lacks
tutorial value. Anyone written up the *right* way to use these? -T
Ignore
I stupidly used random() and srandom() in my module to generate
"random" filenames at high volume and, well, sigh. Anyhow, the page
at http://apr.apache.org/docs/apr/1.3/group__apr__random.html lacks
tutorial value. Anyone written up the *right* way to use these? -T
Ben Collins-Sussman wrote:
On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
Ben Collins-Sussman wrote:
Our solution:
Over at Google, we simply hacked APR to *never* hold on to blocks for
recycling. Essentially, this makes apr_pool_destroy() always free()
the block, and ma
On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Ben Collins-Sussman wrote:
>> Our solution:
>> Over at Google, we simply hacked APR to *never* hold on to blocks for
>> recycling. Essentially, this makes apr_pool_destroy() always free()
>> the block, and makes apr_pool_crea
Ben Collins-Sussman wrote:
> Our solution:
> Over at Google, we simply hacked APR to *never* hold on to blocks for
> recycling. Essentially, this makes apr_pool_destroy() always free()
> the block, and makes apr_pool_create() always call malloc() malloc.
> Poof, all the memory leak went away inst
On Wed, Oct 1, 2008 at 11:11 AM, Ben Collins-Sussman
<[EMAIL PROTECTED]> wrote:
> In the long term, I think we need to question the utility of having
> APR do memory recycling at all. Back in the early 90's, malloc() was
> insanely slow and worth avoiding. In 2008, now that we're running
> apache
11 matches
Mail list logo
