On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz wrote:
> RE "failing the build of my module" -- the dominant usage is via
> precompiled binaries we supply. Is there an apr query for determining
> whether apr was compiled with threads I could do on startup?
I don't think there's an official way b
Thanks Ben,
That might be an interesting hack to try, although I wonder whether some of
our friends running mod_pagespeed on FreeBSD might run into trouble with
it. I did confirm that my prefork build has APR built with
APR_HAS_THREADS, which for some reason I had earlier thought was not the
case
On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz wrote:
> Thanks Ben,
>
> That might be an interesting hack to try, although I wonder whether some of
> our friends running mod_pagespeed on FreeBSD might run into trouble with
> it. I did confirm that my prefork build has APR built with
> APR_HAS_TH
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it w
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
> On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz wrote:
>> Thanks Ben,
>>
>> That might be an interesting hack to try, although I wonder whether some of
>> our friends running mod_pagespeed on FreeBSD might run into trouble with
>> it. I di
On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz wrote:
> On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
>>
>> If dlsym() is called with the special handle NULL, it is interpreted as
>> a
>> reference to the executable or shared object from which the call is
>> being
>> made. Thus
That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
right? That was where I stole my args from.
As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
interface, I'm still not clear on exactly what that means. Does a value of
600 mean that a single multiget
On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz wrote:
> That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> right? That was where I stole my args from.
no, subversion
> As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> interface, I'm still not cle
This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
I need to investigate why some lookups take a second or more. Maybe
there's a mutex contention on my end somewhere.
Thanks!
-Josh
On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick wrote:
> On Thu, Sep 27, 2012 at 1:55 P
