From dev-return-25100-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Nov 1 12:04:53 2012 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BA062DBFD for ; Thu, 1 Nov 2012 12:04:53 +0000 (UTC) Received: (qmail 4412 invoked by uid 500); 1 Nov 2012 12:04:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 3992 invoked by uid 500); 1 Nov 2012 12:04:49 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 3967 invoked by uid 99); 1 Nov 2012 12:04:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 12:04:48 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jmarantz@google.com designates 209.85.210.178 as permitted sender) Received: from [209.85.210.178] (HELO mail-ia0-f178.google.com) (209.85.210.178) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 12:04:43 +0000 Received: by mail-ia0-f178.google.com with SMTP id y26so2324496iab.37 for ; Thu, 01 Nov 2012 05:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=EddXTi0Rfvbg1MoQygCsVe4CyI1h4Bj0TnzDGBtfPKc=; b=UBZytI/ZHWiAHnkVuBUBKAFJ1jIJoyFF+j68mycE7LYJV9fTRcybO/0qU1NX2t9tPt Rhor6fbLxIgNX7fT/rhCZP62JgheEnt770AHK6TltRJKtBk6xRmXI4uF46wCrVT6s6VY vz32thH9EbnAx4U9MIPBoNlCJ3VCdTvfJOCu0aC204snzkRO6vIYZYdi7KkpWczT/5XD TwG7e2D9t5iJO1DOud4dP+xw6f30yLPc7KUQKeZpyCf6l9yjjESJX7c3NE8OdNlooDkE kQ0M/ZywihUQKG+WhUsuKS/VF1KKTwxG09SAQORTrEnPtvjVFUMZvPwOkKjhTooy4+Nk oIHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=EddXTi0Rfvbg1MoQygCsVe4CyI1h4Bj0TnzDGBtfPKc=; b=KKCTabALHQ5/eCa1AlXUZ/de7lpuL5wyuPXbZmbbhiHcbU6IlIdM1/bb4HMPnDEqm3 nDC967rIcHg28ZcAKtEcR/Pbrw8zzPeLl1zz8HZgLudH4hE/+wNg81LzrsltOkHKS8rO NMS0MARrUVi+LGyHrmtB1Flb09xRVFIZeymv67DACOOkwlaikFkmSyZB9QklYBeKkqFv SneoLqm0AcKxMQZjU4S7HTVeZdct+7j8ei2zH2v9xLDyrZa8mpZIFf6RWq+XdUC2inDN vNLIhbPSnUfQtm/8c0N/QNeb0CAJl3sahP3BbY39JIG1otf+oMBKh4g5HDQu2l6uj3Fw WK9g== Received: by 10.50.153.229 with SMTP id vj5mr928941igb.50.1351771462539; Thu, 01 Nov 2012 05:04:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.31.12 with HTTP; Thu, 1 Nov 2012 05:04:01 -0700 (PDT) In-Reply-To: References: From: Joshua Marantz Date: Thu, 1 Nov 2012 08:04:01 -0400 Message-ID: Subject: Re: apr_memcache operation timeouts To: "modules-dev@httpd.apache.org" Cc: dev Content-Type: multipart/mixed; boundary=e89a8f235977d79b0504cd6dd11f X-System-Of-Record: true X-Gm-Message-State: ALoCoQmyi+CATfSbm7SHKvhMqgUpvKzTHBIf/oOt1CNjmoTcfkwcmTZgRxfTMuHjhETjPEdL5zGUxIQeSpZp0RiiKuoijiskxWZ49dfAC37ykhCxX4MulqxaoE2ExFFIMQ0SsHKWrFGVFjuo8bisq39M7YvKY74I3EjvCgaidf5RUaG39Xb69BnYkconLCOEoRqiWJRysbVr X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f235977d79b0504cd6dd11f Content-Type: multipart/alternative; boundary=e89a8f235977d79b0004cd6dd11d --e89a8f235977d79b0004cd6dd11d Content-Type: text/plain; charset=ISO-8859-1 I have completed a solution to this problem, which can be a drop-in update for the existing apr_memcache.c. It is now checked in for my module as http://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/aprutil/apr_memcache2.c . It differs from the solution in https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 in that: - It doesn't require an API change; it but it enforces the 50ms timeout that already exists for apr_multgetp for all operations. - It works under my load test (which I found is not true of the patch in 51065). For my own purposes, I will be shipping my module with apr_memcache2 so I get the behavior I want regardless of what version of Apache is installed. But I'd like to propose my patch for apr_memcache.c. The patch is attached, and I've also submitted it as an alternative patch to bug 51065. If you agree with the strategy I used to solve this problem, then please let me know if I can help with any changes required to get this into the main distribution, On Mon, Oct 22, 2012 at 5:21 PM, Joshua Marantz wrote: > I've had some preliminary success with my own variant of apr_memcache.c > (creatively called apr_memcache2.c). Rather than setting the socket > timeout, I've been mimicing the timeout strategy I saw in > apr_memcache_multgetp, by adding a new helper method: > > static apr_status_t wait_for_server_or_timeout(apr_pool_t* temp_pool, > apr_memcache2_conn_t* conn) > { > apr_pollset_t* pollset; > apr_status_t rv = apr_pollset_create(&pollset, 1, temp_pool, 0); > if (rv == APR_SUCCESS) { > apr_pollfd_t pollfd; > pollfd.desc_type = APR_POLL_SOCKET; > pollfd.reqevents = APR_POLLIN; > pollfd.p = temp_pool; > pollfd.desc.s = conn->sock; > pollfd.client_data = NULL; > apr_pollset_add(pollset, &pollfd); > apr_int32_t queries_recvd; > const apr_pollfd_t* activefds; > rv = apr_pollset_poll(pollset, MULT_GET_TIMEOUT, &queries_recvd, > &activefds); > if (rv == APR_SUCCESS) { > assert(queries_recvd == 1); > assert(activefds->desc.s == conn->sock); > assert(activefds->client_data == NULL); > } > } > return rv; > } > > And calling that before many of the existing calls to get_server_line as: > > rv = wait_for_server_or_timeout_no_pool(conn); > if (rv != APR_SUCCESS) { > ms_release_conn(ms, conn); > return rv; > } > > This is just an experiment; I think I can streamline this by > pre-populating the pollfd structure as part of the apr_memcache_conn_t > (actually now apr_memcache2_conn_t). > > I have two questions about this: > > 1. I noticed the version of apr_memcache.c that ships with Apache 2.4 is > somewhat different from the one that ships with Apache 2.2. In particular > the 2.4 version cannot be compiled against the headers that come with a 2.2 > distribution. Is there any downside to taking my hacked 2.2 apr_memcache.c > and running it in Apache 2.4? Or should I maintain two hacks? > > 2. This seems wasteful in terms of system calls. I am making an extra > call to poll, rather than relying on the socket timeout. The socket > timeout didn't work as well as this though. Does anyone have any theories > as to why, or what could be done to the patch in > https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 to work? > > -Josh > > > On Fri, Oct 19, 2012 at 9:25 AM, Joshua Marantz wrote: > >> Following up: I tried doing what I suggested above: patching that change >> into my own copy of apr_memcache.c It was first of all a bad idea to pull >> in only part of apr_memcache.c because that file changed slightly between >> 2.2 and 2.4 and our module works in both. >> >> I was successful making my own version of apr_memcache (renaming >> entry-points apr_memcache2*) that I could hack. But if I changed the >> socket timeout from -1 to 10 seconds, then the system behaved very poorly >> under load test (though it worked fine in our unit-tests and system-tests). >> In other words, I think the proposed patch that Jeff pointed to above is >> not really working (as he predicted). This test was done without >> SIGSTOPing the memcached; it would timeout under our load anyway and >> thereafter behave poorly. >> >> I'm going to follow up on that bugzilla entry, but for now I'm going to >> pursue my own complicated mechanism of timing out the calls from my side. >> >> -Josh >> >> >> On Thu, Oct 18, 2012 at 10:46 AM, Joshua Marantz wrote: >> >>> Thanks Jeff, that is very helpful. We are considering a course of >>> action and before doing any work toward this, I'd like to understand the >>> pitfalls from people that understand Apache better than us. >>> >>> Here's our reality: we believe we need to incorporate memcached for >>> mod_pagespeed to scale effectively for very >>> large sites & hosting providers. We are fairly close (we think) to >>> releasing this functionality as beta. However, in such large sites, stuff >>> goes wrong: machines crash, power failure, fiber cut, etc. When it does we >>> want to fall back to serving partially unoptimized sites rather than >>> hanging the servers. >>> >>> I understand the realities of backward-compatible APIs. My expectation >>> is that this would take years to make it into an APR distribution we could >>> depend on. We want to deploy this functionality in weeks. The workarounds >>> we have tried backgrounding the apr_memcache calls in a thread and timing >>> out in mainline are complex and even once they work 100% will be very >>> unsatisfactory (resource leaks; Apache refusing to exit cleanly on >>> 'apachectl stop') if this happens more than (say) once a month. >>> >>> Our plan is to copy the patched implementation of >>> apr_memcache_server_connect and the static methods it calls into a new .c >>> file we will link into our module, naming the new entry-point something >>> else (apr_memcache_server_connect_with_timeout seems good). From a >>> CS/SE perspective this is offensive and we admit it, but from a product >>> quality perspective we believe this beats freezes and complicated/imperfect >>> workarounds with threads. >>> >>> So I have two questions for the Apache community: >>> >>> 1. What are the practical problems with this approach? Note that in >>> any case a new APR rev would require editing/ifdefing our code anyway, so I >>> think immunity from APR updates such as this patch being applied is not a >>> distinguishing drawback. >>> 2. Is there an example of the correct solution to the technical >>> problem Jeff highlighted: "it is apparently missing a call to adjust >>> the socket timeout and to discard the connection if the timeout is reached". >>> That sounds like a pattern that might be found elsewhere in the Apache >>> HTTPD code base. >>> >>> Thanks in advance for your help! >>> -Josh >>> >>> >>> On Wed, Oct 17, 2012 at 8:16 PM, Jeff Trawick wrote: >>> >>>> On Wed, Oct 17, 2012 at 3:36 PM, Joshua Marantz >>>> wrote: >>>> > Is there a mechanism to time out individual operations? >>>> >>>> No, the socket connect timeout is hard-coded at 1 second and the >>>> socket I/O timeout is disabled. >>>> >>>> Bugzilla bug https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 >>>> has a patch, though it is apparently missing a call to adjust the >>>> socket timeout and to discard the connection if the timeout is >>>> reached. More importantly, the API can only be changed in future APR >>>> 2.0; alternate, backwards-compatible API(s) could be added in future >>>> APR-Util 1.6. >>>> >>>> > >>>> > If memcached freezes, then it appears my calls to 'get' will block >>>> until >>>> > memcached wakes up. Is there any way to set a timeout for that call? >>>> > >>>> > I can repro this in my unit tests by sending a SIGSTOP to memcached >>>> before >>>> > doing a 'get'? >>>> > >>>> > Here are my observations: >>>> > >>>> > apr_memcache_multgetp seems to time out in bounded time if I SIGSTOP >>>> the >>>> > memcached process. Yes! >>>> > >>>> > apr_memcache_getp seems to hang indefinitely if I SIGSTOP the >>>> memcached >>>> > process. >>>> > >>>> > apr_memcache_set seems to hang indefinitely if I SIGSTOP the memcached >>>> > process. >>>> > >>>> > apr_memcache_delete seems to hang indefinitely if I SIGSTOP the >>>> memcached >>>> > process. >>>> > >>>> > apr_memcache_stats seems to hang indefinitely if I SIGSTOP the >>>> memcached >>>> > process. >>>> > >>>> > That last one really sucks as I am using that to print the status of >>>> all my >>>> > cache shards to the log file if I detected a problem :( >>>> > >>>> > >>>> > Why does apr_memcache_multgetp do what I want and not the others? >>>> Can I >>>> > induce the others to have reasonable timeout behavior? >>>> > >>>> > When I SIGSTOP memcached this makes it hard to even restart Apache, at >>>> > least with graceful-stop. >>>> > >>>> > >>>> > On a related note, the apr_memcache >>>> > documentation< >>>> http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___m_c.html >>>> >is >>>> > very thin. I'd be happy to augment it with my observations on its >>>> > usage >>>> > and the meaning of some of the arguments if that was desired. How >>>> would I >>>> > go about that? >>>> >>>> Check out APR trunk from Subversion, adjust the doxygen docs in the >>>> include files, build (make dox) and inspect the results, submit a >>>> patch to dev@apr.apache.org. >>>> >>>> > >>>> > -Josh >>>> >>>> >>>> >>>> -- >>>> Born in Roswell... married an alien... >>>> http://emptyhammock.com/ >>>> >>> >>> >> > --e89a8f235977d79b0004cd6dd11d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have= completed a solution to this problem, which can be a drop-in update for th= e existing apr_memcache.c. =A0It is now checked in for my module as=A0http://code.google.com/p/modpagespeed/source/= browse/trunk/src/third_party/aprutil/apr_memcache2.c.

It differs from the solution in=A0https://issues.apache.org/bu= gzilla/show_bug.cgi?id=3D51065=A0in that:
  • It doesn't require an API change; it but it enforces the 5= 0ms timeout that already exists for apr_multgetp for all operations.
  • It works under my load test (which I found is not true of the patch i= n 51065).
For my own purposes, I will be shipping my module with= apr_memcache2 so I get the behavior I want regardless of what version of A= pache is installed. =A0But I'd like to propose my patch for apr_memcach= e.c. =A0The patch is attached, and I've also submitted it as an alterna= tive patch to bug 51065.

If you agree with the strategy I used to solve this pro= blem, then please let me know if I can help with any changes required to ge= t this into the main distribution,=A0


On Mon, Oct 2= 2, 2012 at 5:21 PM, Joshua Marantz <jmarantz@google.com> w= rote:
I've had some preliminary success with m= y own variant of apr_memcache.c (creatively called apr_memcache2.c). =A0Rat= her than setting the socket timeout, I've been mimicing the timeout str= ategy I saw in apr_memcache_multgetp, by adding a new helper method:

static apr_status= _t wait_for_server_or_timeout(apr_pool_t* temp_pool,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0apr_memcache2_conn_t= * conn) {
=A0 =A0 apr_pollset_t* pollset;<= /font>
=A0 =A0 apr_status_t= rv =3D apr_pollset_create(&pollset, 1, temp_pool, 0);
=A0 =A0 if (rv =3D=3D APR_SUCCESS) {=
=A0 =A0 =A0 =A0 apr_pollfd_t pol= lfd;
=A0 =A0 =A0 =A0= pollfd.desc_type =3D APR_POLL_SOCKET;
=A0 =A0 =A0 =A0 pollfd.reqevents =3D APR_POLLIN;<= /div>
=A0 =A0 =A0 =A0 pollfd.p =3D tem= p_pool;
=A0 =A0 =A0 = =A0 pollfd.desc.s =3D conn->sock;
=A0 =A0 =A0 =A0 pollfd.client_data =3D NULL;
=A0 =A0 =A0 =A0 apr_pollset_add(= pollset, &pollfd);
=A0 =A0 =A0 =A0 apr_int32_t queries_recvd;
=A0 =A0 =A0 =A0 const apr_pollfd_t* activefds;<= /font>
=A0 =A0 =A0 =A0 rv =3D apr_polls= et_poll(pollset, MULT_GET_TIMEOUT, &queries_recvd,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 &activefds);
=A0 =A0 =A0 =A0 if (rv =3D=3D AP= R_SUCCESS) {
=A0 =A0= =A0 =A0 =A0 =A0 assert(queries_recvd =3D=3D 1);
=A0 =A0 =A0 =A0 =A0 =A0 assert(activefds->d= esc.s =3D=3D conn->sock);
=A0 =A0 =A0 =A0 =A0 =A0 assert(a= ctivefds->client_data =3D=3D NULL);
=A0 =A0 =A0 =A0 }
=A0 =A0 }
=A0 =A0 return rv;
<= div>}

And calling that before many of the existing calls to get_server_lin= e as:

=A0 =A0 rv = =3D wait_for_server_or_timeout_no_pool(conn);
=A0 =A0 if (rv !=3D APR_SUCCESS) {
=
=A0 =A0 =A0 =A0 ms_release_conn(= ms, conn);
=A0 =A0 =A0 =A0 return rv;
=A0 =A0 }

This is just an experiment; I think I can streamline this by pre-popu= lating the pollfd structure as part of the apr_memcache_conn_t (actually no= w apr_memcache2_conn_t).

I have two questions about this:

1. I noticed the version of apr_memcache.c that ships with Apache = 2.4 is somewhat different from the one that ships with Apache 2.2. =A0In pa= rticular the 2.4 version cannot be compiled against the headers that come w= ith a 2.2 distribution. =A0Is there any downside to taking my hacked 2.2 ap= r_memcache.c and running it in Apache 2.4? =A0Or should I maintain two hack= s?

2. This seems wasteful in terms of system calls. =A0I a= m making an extra call to poll, rather than relying on the socket timeout. = =A0The socket timeout didn't work as well as this though. =A0Does anyon= e have any theories as to why, or what could be done to the patch in=A0https://iss= ues.apache.org/bugzilla/show_bug.cgi?id=3D51065=A0to work?

-Josh


On Fri, Oct 19, 2= 012 at 9:25 AM, Joshua Marantz <jmarantz@google.com> wrote= :
Following up: I tried doing what I suggested= above: patching that change into my own copy of apr_memcache.c =A0It was f= irst of all a bad idea to pull in only part of apr_memcache.c because that = file changed slightly between 2.2 and 2.4 and our module works in both.
I was successful making my own version of apr_memcache (renaming entry-= points apr_memcache2*) that I could hack. =A0But if I changed the socket ti= meout from -1 to 10 seconds, then the system behaved very poorly under load= test (though it worked fine in our unit-tests and system-tests). =A0In oth= er words, I think the proposed patch that Jeff pointed to above is not real= ly working (as he predicted). =A0This test was done without SIGSTOPing the = memcached; it would timeout under our load anyway and thereafter behave poo= rly.

I'm going to follow up on that bugzilla entry, but = for now I'm going to pursue my own complicated mechanism of timing out = the calls from my side.

-Josh


On Thu, Oct 18, 2012 at 10:46 AM, Joshua= Marantz <jmarantz@google.com> wrote:
Thanks Jeff, that is very helpful. =A0We are considering a course of action= and before doing any work toward this, I'd like to understand the pitf= alls from people that understand Apache better than us.

Here's our reality: we believe we need to incorporate memcached for=A0<= a href=3D"http://modpagespeed.com" target=3D"_blank">mod_pagespeed=A0to= scale effectively for very large sites & hosting providers. =A0We are = fairly close (we think) to releasing this functionality as beta. =A0However= , in such large sites, stuff goes wrong: machines crash, power failure, fib= er cut, etc. =A0When it does we want to fall back to serving partially unop= timized sites rather than hanging the servers.

I understand the realities of backward-compatible APIs.= =A0My expectation is that this would take years to make it into an APR dis= tribution we could depend on. =A0We want to deploy this functionality in we= eks. =A0The workarounds we have tried backgrounding the apr_memcache calls = in a thread and timing out in mainline are complex and even once they work = 100% will be very unsatisfactory (resource leaks; Apache refusing to exit c= leanly on 'apachectl stop') if this happens more than (say) once a = month.

Our plan is to copy the patched implementation of apr_m= emcache_server_connect and the static methods it calls into a new .c file w= e will link into our module, naming the new entry-point something else (apr_memcache_server_connect_with_timeout= seems good). =A0From a CS/SE perspective this is offensive and we a= dmit it, but from a product quality perspective we believe this beats freez= es and complicated/imperfect workarounds with threads.

So I have two questions for the Apache community:
=
  1. What are the practical problems with this approach? =A0Note th= at in any case a new APR rev would require editing/ifdefing our code anyway= , so I think immunity from APR updates such as this patch being applied is = not a distinguishing drawback.
  2. Is there an example of the correct solution to the technical probl= em Jeff highlighted: "it is apparently missing a call to adjust the=A0socket timeout and to d= iscard the connection if the timeout is=A0reached". =A0That sounds like a patt= ern that might be found elsewhere in the Apache HTTPD code base.
Thanks in advance for your help!
-Josh


On Wed, Oct 17, 2012 at 8:16 PM, Jeff Tr= awick <trawick@gmail.com> wrote:
On Wed, Oct 17, 2012 at 3:36 PM, Joshua Marantz <jmarantz@google.com> wrote: > Is there a mechanism to time out individual operations?

No, the socket connect timeout is hard-coded at 1 second and the
socket I/O timeout is disabled.

Bugzilla bug https://issues.apache.org/bugzilla/show_bug.cgi= ?id=3D51065
has a patch, though it is apparently missing a call to adjust the
socket timeout and to discard the connection if the timeout is
reached. =A0More importantly, the API can only be changed in future APR
2.0; alternate, backwards-compatible API(s) could be added in future
APR-Util 1.6.

>
> If memcached freezes, then it appears my calls to 'get' will b= lock until
> memcached wakes up. =A0Is there any way to set a timeout for that call= ?
>
> I can repro this in my unit tests by sending a SIGSTOP to memcached be= fore
> doing a 'get'?
>
> Here are my observations:
>
> apr_memcache_multgetp seems to time out in bounded time if I SIGSTOP t= he
> memcached process. Yes!
>
> apr_memcache_getp seems to hang indefinitely if I SIGSTOP the memcache= d
> process.
>
> apr_memcache_set seems to hang indefinitely if I SIGSTOP the memcached=
> process.
>
> apr_memcache_delete seems to hang indefinitely if I SIGSTOP the memcac= hed
> process.
>
> apr_memcache_stats seems to hang indefinitely if I SIGSTOP the memcach= ed
> process.
>
> That last one really sucks as I am using that to print the status of a= ll my
> cache shards to the log file if I detected a problem :(
>
>
> Why does apr_memcache_multgetp do what I want and not the others? =A0C= an I
> induce the others to have reasonable timeout behavior?
>
> When I SIGSTOP memcached this makes it hard to even restart Apache, at=
> least with graceful-stop.
>
>
> On a related note, the apr_memcache
> documentation<http://apr.apache.or= g/docs/apr-util/1.4/group___a_p_r___util___m_c.html>is
> very thin. =A0I'd be happy to augment it with my observations= on its
> usage
> and the meaning of some of the arguments if that was desired. =A0How w= ould I
> go about that?

Check out APR trunk from Subversion, adjust the doxygen docs in the include files, build (make dox) and inspect the results, submit a
patch to dev@apr.ap= ache.org.

>
> -Josh



--
Born in Roswell... married an alien...
http://emptyhammock.= com/




--e89a8f235977d79b0004cd6dd11d-- --e89a8f235977d79b0504cd6dd11f Content-Type: application/octet-stream; name="apr_memcache_timeout.diff" Content-Disposition: attachment; filename="apr_memcache_timeout.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8zth7ja0 SW5kZXg6IHRoaXJkX3BhcnR5L2FwcnV0aWwvYXByX21lbWNhY2hlLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g dGhpcmRfcGFydHkvYXBydXRpbC9hcHJfbWVtY2FjaGUuYwkocmV2aXNpb24gMjEyMSkKKysrIHRo aXJkX3BhcnR5L2FwcnV0aWwvYXByX21lbWNhY2hlLmMJKHdvcmtpbmcgY29weSkKQEAgLTE3LDYg KzE3LDcgQEAKICNpbmNsdWRlICJhcHJfbWVtY2FjaGUuaCIKICNpbmNsdWRlICJhcHJfcG9sbC5o IgogI2luY2x1ZGUgImFwcl92ZXJzaW9uLmgiCisjaW5jbHVkZSA8YXNzZXJ0Lmg+CiAjaW5jbHVk ZSA8c3RkbGliLmg+CiAKICNkZWZpbmUgQlVGRkVSX1NJWkUgNTEyCkBAIC0zMCw4ICszMSwxOCBA QAogICAgIGFwcl9idWNrZXRfYnJpZ2FkZSAqYmI7CiAgICAgYXByX2J1Y2tldF9icmlnYWRlICp0 YjsKICAgICBhcHJfbWVtY2FjaGVfc2VydmVyX3QgKm1zOworICAgIGFwcl9wb2xsc2V0X3QqIHBv bGxzZXQ7ICAvKiBTZXQtdXAgdG8gcG9sbCBvbmx5IGZvciB0aGlzIG9uZSBjb25uZWN0aW9uICov CiB9OwogCisvKioKKyAqIEluZGljYXRlcyB3aGV3dGhlciBhIGxvY2sgaXMgaGVsZCB3aGVuIGNh bGxpbmcgaGVscGVyIGZ1bmN0aW9ucyBmcm9tIGVpdGhlcgorICogc3RhdGUuCisgKi8KK3R5cGVk ZWYgZW51bSB7CisgIExPQ0tfTk9UX0hFTEQsCisgIExPQ0tfSEVMRAorfSBsb2NrX3N0YXR1c190 OworCiAvKiBTdHJpbmdzIGZvciBDbGllbnQgQ29tbWFuZHMgKi8KIAogI2RlZmluZSBNQ19FT0wg IlxyXG4iCkBAIC0xMDksMTUgKzEyMCwyMCBAQAogCiAjZGVmaW5lIE1VTFRfR0VUX1RJTUVPVVQg NTAwMDAKIAotc3RhdGljIGFwcl9zdGF0dXNfdCBtYWtlX3NlcnZlcl9kZWFkKGFwcl9tZW1jYWNo ZV90ICptYywgYXByX21lbWNhY2hlX3NlcnZlcl90ICptcykKK3N0YXRpYyBhcHJfc3RhdHVzX3Qg bWFya19zZXJ2ZXJfZGVhZChhcHJfbWVtY2FjaGVfc2VydmVyX3QgKm1zLAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGxvY2tfc3RhdHVzX3QgbG9ja19zdGF0dXMpCiB7CiAj aWYgQVBSX0hBU19USFJFQURTCi0gICAgYXByX3RocmVhZF9tdXRleF9sb2NrKG1zLT5sb2NrKTsK KyAgICBpZiAobG9ja19zdGF0dXMgPT0gTE9DS19OT1RfSEVMRCkgeworICAgICAgICBhcHJfdGhy ZWFkX211dGV4X2xvY2sobXMtPmxvY2spOworICAgIH0KICNlbmRpZgogICAgIG1zLT5zdGF0dXMg PSBBUFJfTUNfU0VSVkVSX0RFQUQ7CiAgICAgbXMtPmJ0aW1lID0gYXByX3RpbWVfbm93KCk7CiAj aWYgQVBSX0hBU19USFJFQURTCi0gICAgYXByX3RocmVhZF9tdXRleF91bmxvY2sobXMtPmxvY2sp OworICAgIGlmIChsb2NrX3N0YXR1cyA9PSBMT0NLX05PVF9IRUxEKSB7CisgICAgICAgIGFwcl90 aHJlYWRfbXV0ZXhfdW5sb2NrKG1zLT5sb2NrKTsKKyAgICB9CiAjZW5kaWYKICAgICByZXR1cm4g QVBSX1NVQ0NFU1M7CiB9CkBAIC0xMzksMTEgKzE1NSwxMiBAQAogCiAgICAgbWMtPmxpdmVfc2Vy dmVyc1ttYy0+bnRvdGFsXSA9IG1zOwogICAgIG1jLT5udG90YWwrKzsKKyAgICBtcy0+bWVtY2Fj aGUgPSBtYzsKICAgICBtYWtlX3NlcnZlcl9saXZlKG1jLCBtcyk7CiAgICAgcmV0dXJuIHJ2Owog fQogCi1zdGF0aWMgYXByX3N0YXR1c190IG1jX3ZlcnNpb25fcGluZyhhcHJfbWVtY2FjaGVfc2Vy dmVyX3QgKm1zKTsKK3N0YXRpYyBhcHJfc3RhdHVzX3QgbWNfdmVyc2lvbl9waW5nX2xvY2tfaGVs ZChhcHJfbWVtY2FjaGVfc2VydmVyX3QgKm1zKTsKIAogQVBVX0RFQ0xBUkUoYXByX21lbWNhY2hl X3NlcnZlcl90ICopCiBhcHJfbWVtY2FjaGVfZmluZF9zZXJ2ZXJfaGFzaChhcHJfbWVtY2FjaGVf dCAqbWMsIGNvbnN0IGFwcl91aW50MzJfdCBoYXNoKQpAQCAtMTgxLDkgKzE5OCw5IEBACiAjaWYg QVBSX0hBU19USFJFQURTCiAgICAgICAgICAgICBhcHJfdGhyZWFkX211dGV4X2xvY2sobXMtPmxv Y2spOwogI2VuZGlmCi0gICAgICAgICAgICAvKiBUcnkgdGhlIHRoZSBkZWFkIHNlcnZlciwgZXZl cnkgNSBzZWNvbmRzICovCisgICAgICAgICAgICAvKiBUcnkgdGhlIHRoZSBkZWFkIHNlcnZlciwg ZXZlcnkgNSBzZWNvbmRzLCBrZWVwaW5nIHRoZSBsb2NrLiAqLwogICAgICAgICAgICAgaWYgKGN1 cnRpbWUgLSBtcy0+YnRpbWUgPiAgYXByX3RpbWVfZnJvbV9zZWMoNSkpIHsKLSAgICAgICAgICAg ICAgICBpZiAobWNfdmVyc2lvbl9waW5nKG1zKSA9PSBBUFJfU1VDQ0VTUykgeworICAgICAgICAg ICAgICAgIGlmIChtY192ZXJzaW9uX3BpbmdfbG9ja19oZWxkKG1zKSA9PSBBUFJfU1VDQ0VTUykg ewogICAgICAgICAgICAgICAgICAgICBtcy0+YnRpbWUgPSBjdXJ0aW1lOwogICAgICAgICAgICAg ICAgICAgICBtYWtlX3NlcnZlcl9saXZlKG1jLCBtcyk7CiAjaWYgQVBSX0hBU19USFJFQURTCkBA IC0yODIsOSArMjk5LDUyIEBACiAKIEFQVV9ERUNMQVJFKGFwcl9zdGF0dXNfdCkgYXByX21lbWNh Y2hlX2Rpc2FibGVfc2VydmVyKGFwcl9tZW1jYWNoZV90ICptYywgYXByX21lbWNhY2hlX3NlcnZl cl90ICptcykKIHsKLSAgICByZXR1cm4gbWFrZV9zZXJ2ZXJfZGVhZChtYywgbXMpOworICAgIGFz c2VydChtYyA9PSBtcy0+bWVtY2FjaGUpOworICAgIHJldHVybiBtYXJrX3NlcnZlcl9kZWFkKG1z LCBMT0NLX05PVF9IRUxEKTsKIH0KIAorLyoKKyAqIENsZWFucyB1cCBjb25uZWN0aW9ucyBhbmQv b3IgYmFkIHNlcnZlcnMgYXMgcmVxdWlyZWQuCisgKgorICogVGhpcyBmdW5jdGlvbiBzaG91bGQg b25seSBiZSBjYWxsZWQgaWYgcnYgaXMgbm90IEFQUl9TVUNDRVNTLgorICovCitzdGF0aWMgdm9p ZCBkaXNhYmxlX3NlcnZlcl9hbmRfY29ubmVjdGlvbihhcHJfbWVtY2FjaGVfc2VydmVyX3QgKm1z LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9ja19zdGF0dXNf dCBsb2NrX3N0YXR1cywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGFwcl9tZW1jYWNoZV9jb25uX3QgKmNvbm4pIHsKKyAgICBpZiAoY29ubiAhPSBOVUxMKSB7Cisg ICAgICAgIG1zX2JhZF9jb25uKG1zLCBjb25uKTsKKyAgICB9CisgICAgbWFya19zZXJ2ZXJfZGVh ZChtcywgbG9ja19zdGF0dXMpOworfQorCisvKgorICogUG9sbHMgYSBzb2NrZXQgdG8gc2VlIHdo ZXRoZXIgdGhlIG5leHQgSS9PIG9wZXJhdGlvbiBjYWxsIHdpbGwgYmxvY2suCisgKiBUaGUgc3Rh dHVzIHJldHVybmVkIGlzIGJhc2VkIG9uIGFwcl9wb2xsc2V0X3BvbGw6CisgKiBodHRwOi8vYXBy LmFwYWNoZS5vcmcvZG9jcy9hcHIvdHJ1bmsvZ3JvdXBfX2Fwcl9fcG9sbC5odG1sI2dhNmIzMWQ3 YjNhN2IyZDM1NjM3MDQwM2RkMmI3OWVjZjMKKyAqCisgKiBJbiBwcmFjdGljZSB0aGlzIGFwcGVh cnMgdG8gcmV0dXJuIEFQUl9USU1FVVAgb24gdGltZW91dCAoaGFyZGNvZGVkIHRvIDUwbXMpLgor ICoKKyAqIFJldHVybnMgQVBSX1NVQ0NFU1NTIGlmIGl0J3MgT0sgdG8gcmVhZC4gIE90aGVyd2lz ZSBpdCByZWxlYXNlcyB0aGUKKyAqIGNvbm5lY3Rpb24gYW5kIHJldHVybnMgdGhlIHN0YXR1cy4K KyAqLworc3RhdGljIGFwcl9zdGF0dXNfdCBwb2xsX3NlcnZlcl9yZWxlYXNpbmdfY29ubmVjdGlv bl9vbl9mYWlsdXJlKAorICAgIGFwcl9tZW1jYWNoZV9zZXJ2ZXJfdCAqbXMsCisgICAgbG9ja19z dGF0dXNfdCBsb2NrX3N0YXR1cywKKyAgICBhcHJfbWVtY2FjaGVfY29ubl90ICpjb25uKSB7Cisg ICAgYXByX2ludDMyX3QgcXVlcmllc19yZWN2ZDsKKyAgICBjb25zdCBhcHJfcG9sbGZkX3QqIGFj dGl2ZWZkczsKKyAgICBhcHJfc3RhdHVzX3QgcnYgPSBhcHJfcG9sbHNldF9wb2xsKGNvbm4tPnBv bGxzZXQsIE1VTFRfR0VUX1RJTUVPVVQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmcXVlcmllc19yZWN2ZCwgJmFjdGl2ZWZkcyk7CisgICAgaWYgKHJ2ID09IEFQUl9T VUNDRVNTKSB7CisgICAgICAgIGFzc2VydChxdWVyaWVzX3JlY3ZkID09IDEpOworICAgICAgICBh c3NlcnQoYWN0aXZlZmRzLT5kZXNjLnMgPT0gY29ubi0+c29jayk7CisgICAgICAgIGFzc2VydChh Y3RpdmVmZHMtPmNsaWVudF9kYXRhID09IE5VTEwpOworICAgIH0gZWxzZSB7CisgICAgICAgIGRp c2FibGVfc2VydmVyX2FuZF9jb25uZWN0aW9uKG1zLCBsb2NrX3N0YXR1cywgY29ubik7CisgICAg fQorICAgIHJldHVybiBydjsKK30KKwogc3RhdGljIGFwcl9zdGF0dXNfdCBjb25uX2Nvbm5lY3Qo YXByX21lbWNhY2hlX2Nvbm5fdCAqY29ubikKIHsKICAgICBhcHJfc3RhdHVzX3QgcnYgPSBBUFJf U1VDQ0VTUzsKQEAgLTM0MywxMiArNDAzLDIwIEBACiAgICAgYXByX3Bvb2xfdCAqbnA7CiAgICAg YXByX3Bvb2xfdCAqdHA7CiAgICAgYXByX21lbWNhY2hlX3NlcnZlcl90ICptcyA9IHBhcmFtczsK KyAgICBhcHJfcG9sbHNldF90KiBwb2xsc2V0ID0gTlVMTDsKIAogICAgIHJ2ID0gYXByX3Bvb2xf Y3JlYXRlKCZucCwgcG9vbCk7CiAgICAgaWYgKHJ2ICE9IEFQUl9TVUNDRVNTKSB7CiAgICAgICAg IHJldHVybiBydjsKICAgICB9CiAKKyAgICAvKiBQcmUtYWxsb2NhdGUgYSBwb2xsc2V0IGF0IGEg cG9pbnQgd2hlcmUgaXQncyBlYXN5IHRvIGJhaWwgb24gZmFpbHVyZS4gKi8KKyAgICBydiA9IGFw cl9wb2xsc2V0X2NyZWF0ZSgmcG9sbHNldCwgMSwgbnAsIDApOworICAgIGlmIChydiAhPSBBUFJf U1VDQ0VTUykgeworICAgICAgICBhcHJfcG9vbF9kZXN0cm95KG5wKTsKKyAgICAgICAgcmV0dXJu IHJ2OworICAgIH0KKwogICAgIHJ2ID0gYXByX3Bvb2xfY3JlYXRlKCZ0cCwgbnApOwogICAgIGlm IChydiAhPSBBUFJfU1VDQ0VTUykgewogICAgICAgICBhcHJfcG9vbF9kZXN0cm95KG5wKTsKQEAg LTM4OCw2ICs0NTYsMTkgQEAKICAgICBlbHNlIHsKICAgICAgICAgYXByX3Bvb2xfY2xlYW51cF9y ZWdpc3RlcihucCwgY29ubiwgY29ubl9jbGVhbiwgYXByX3Bvb2xfY2xlYW51cF9udWxsKTsKICAg ICAgICAgKmNvbm5fID0gY29ubjsKKworICAgICAgICAvKgorICAgICAgICAgKiBQb3B1bGF0ZSBh biAnaXMgcmVhZGFibGUnIHBvbGxzZXQgZm9yIHRoaXMgc29ja2V0IHRvIGFsbG93IGVhcmx5Cisg ICAgICAgICAqIHRpbWVvdXQgZGV0ZWN0aW9uLgorICAgICAgICAgKi8KKyAgICAgICAgY29ubi0+ cG9sbHNldCA9IHBvbGxzZXQ7CisgICAgICAgIGFwcl9wb2xsZmRfdCBwb2xsZmQ7CisgICAgICAg IHBvbGxmZC5kZXNjX3R5cGUgPSBBUFJfUE9MTF9TT0NLRVQ7CisgICAgICAgIHBvbGxmZC5yZXFl dmVudHMgPSBBUFJfUE9MTElOOworICAgICAgICBwb2xsZmQucCA9IG5wOworICAgICAgICBwb2xs ZmQuZGVzYy5zID0gY29ubi0+c29jazsKKyAgICAgICAgcG9sbGZkLmNsaWVudF9kYXRhID0gTlVM TDsKKyAgICAgICAgYXByX3BvbGxzZXRfYWRkKGNvbm4tPnBvbGxzZXQsICZwb2xsZmQpOwogICAg IH0KIAogICAgIHJldHVybiBydjsKQEAgLTQyNyw2ICs1MDgsNyBAQAogICAgIHNlcnZlci0+aG9z dCA9IGFwcl9wc3RyZHVwKG5wLCBob3N0KTsKICAgICBzZXJ2ZXItPnBvcnQgPSBwb3J0OwogICAg IHNlcnZlci0+c3RhdHVzID0gQVBSX01DX1NFUlZFUl9ERUFEOworICAgIHNlcnZlci0+bWVtY2Fj aGUgPSBOVUxMOwogI2lmIEFQUl9IQVNfVEhSRUFEUwogICAgIHJ2ID0gYXByX3RocmVhZF9tdXRl eF9jcmVhdGUoJnNlcnZlci0+bG9jaywgQVBSX1RIUkVBRF9NVVRFWF9ERUZBVUxULCBucCk7CiAg ICAgaWYgKHJ2ICE9IEFQUl9TVUNDRVNTKSB7CkBAIC02MDcsNiArNjg5LDMzIEBACiAgICAgcmV0 dXJuIGFwcl9icmlnYWRlX2NsZWFudXAoY29ubi0+dGIpOwogfQogCitzdGF0aWMgYXByX3N0YXR1 c190IHNlbmR2X2FuZF9nZXRfc2VydmVyX2xpbmVfd2l0aF90aW1lb3V0KAorICAgIGFwcl9tZW1j YWNoZV9zZXJ2ZXJfdCAqbXMsCisgICAgYXByX21lbWNhY2hlX2Nvbm5fdCAqY29ubiwKKyAgICBz dHJ1Y3QgaW92ZWMqIHZlYywKKyAgICBpbnQgdmVjX3NpemUsCisgICAgbG9ja19zdGF0dXNfdCBs b2NrX3N0YXR1cykgeworCisgICAgYXByX3NpemVfdCB3cml0dGVuOworICAgIGFwcl9zdGF0dXNf dCBydiA9IGFwcl9zb2NrZXRfc2VuZHYoY29ubi0+c29jaywgdmVjLCB2ZWNfc2l6ZSwgJndyaXR0 ZW4pOworICAgIGlmIChydiAhPSBBUFJfU1VDQ0VTUykgeworICAgICAgICBkaXNhYmxlX3NlcnZl cl9hbmRfY29ubmVjdGlvbihtcywgbG9ja19zdGF0dXMsIGNvbm4pOworICAgICAgICByZXR1cm4g cnY7CisgICAgfQorCisgICAgcnYgPSBwb2xsX3NlcnZlcl9yZWxlYXNpbmdfY29ubmVjdGlvbl9v bl9mYWlsdXJlKG1zLCBsb2NrX3N0YXR1cywgY29ubik7CisgICAgaWYgKHJ2ICE9IEFQUl9TVUND RVNTKSB7CisgICAgICAgIHJldHVybiBydjsKKyAgICB9CisKKyAgICBydiA9IGdldF9zZXJ2ZXJf bGluZShjb25uKTsKKyAgICBpZiAocnYgIT0gQVBSX1NVQ0NFU1MpIHsKKyAgICAgICAgZGlzYWJs ZV9zZXJ2ZXJfYW5kX2Nvbm5lY3Rpb24obXMsIExPQ0tfTk9UX0hFTEQsIGNvbm4pOworICAgIH0K KworICAgIHJldHVybiBydjsKK30KKwogc3RhdGljIGFwcl9zdGF0dXNfdCBzdG9yYWdlX2NtZF93 cml0ZShhcHJfbWVtY2FjaGVfdCAqbWMsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IGNoYXIgKmNtZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29uc3QgYXByX3NpemVfdCBjbWRfc2l6ZSwKQEAgLTYyMCw3ICs3MjksNiBAQAogICAg IGFwcl9tZW1jYWNoZV9zZXJ2ZXJfdCAqbXM7CiAgICAgYXByX21lbWNhY2hlX2Nvbm5fdCAqY29u bjsKICAgICBhcHJfc3RhdHVzX3QgcnY7Ci0gICAgYXByX3NpemVfdCB3cml0dGVuOwogICAgIHN0 cnVjdCBpb3ZlYyB2ZWNbNV07CiAgICAgYXByX3NpemVfdCBrbGVuOwogCkBAIC02NjAsMjIgKzc2 OCwxMiBAQAogICAgIHZlY1s0XS5pb3ZfYmFzZSA9IChjaGFyKikgTUNfRU9MOwogICAgIHZlY1s0 XS5pb3ZfbGVuICA9IE1DX0VPTF9MRU47CiAKLSAgICBydiA9IGFwcl9zb2NrZXRfc2VuZHYoY29u bi0+c29jaywgdmVjLCA1LCAmd3JpdHRlbik7Ci0KKyAgICBydiA9IHNlbmR2X2FuZF9nZXRfc2Vy dmVyX2xpbmVfd2l0aF90aW1lb3V0KG1zLCBjb25uLCB2ZWMsIDUsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMT0NLX05PVF9IRUxEKTsKICAgICBpZiAo cnYgIT0gQVBSX1NVQ0NFU1MpIHsKLSAgICAgICAgbXNfYmFkX2Nvbm4obXMsIGNvbm4pOwotICAg ICAgICBhcHJfbWVtY2FjaGVfZGlzYWJsZV9zZXJ2ZXIobWMsIG1zKTsKICAgICAgICAgcmV0dXJu IHJ2OwogICAgIH0KIAotICAgIHJ2ID0gZ2V0X3NlcnZlcl9saW5lKGNvbm4pOwotCi0gICAgaWYg KHJ2ICE9IEFQUl9TVUNDRVNTKSB7Ci0gICAgICAgIG1zX2JhZF9jb25uKG1zLCBjb25uKTsKLSAg ICAgICAgYXByX21lbWNhY2hlX2Rpc2FibGVfc2VydmVyKG1jLCBtcyk7Ci0gICAgICAgIHJldHVy biBydjsKLSAgICB9Ci0KICAgICBpZiAoc3RyY21wKGNvbm4tPmJ1ZmZlciwgTVNfU1RPUkVEIE1D X0VPTCkgPT0gMCkgewogICAgICAgICBydiA9IEFQUl9TVUNDRVNTOwogICAgIH0KQEAgLTc0OSw3 ICs4NDcsNiBAQAogICAgIGFwcl9tZW1jYWNoZV9zZXJ2ZXJfdCAqbXM7CiAgICAgYXByX21lbWNh Y2hlX2Nvbm5fdCAqY29ubjsKICAgICBhcHJfdWludDMyX3QgaGFzaDsKLSAgICBhcHJfc2l6ZV90 IHdyaXR0ZW47CiAgICAgYXByX3NpemVfdCBrbGVuID0gc3RybGVuKGtleSk7CiAgICAgc3RydWN0 IGlvdmVjIHZlY1szXTsKIApAQCAtNzc1LDIxICs4NzIsMTIgQEAKICAgICB2ZWNbMl0uaW92X2Jh c2UgPSAoY2hhciopIE1DX0VPTDsKICAgICB2ZWNbMl0uaW92X2xlbiAgPSBNQ19FT0xfTEVOOwog Ci0gICAgcnYgPSBhcHJfc29ja2V0X3NlbmR2KGNvbm4tPnNvY2ssIHZlYywgMywgJndyaXR0ZW4p OwotCisgICAgcnYgPSBzZW5kdl9hbmRfZ2V0X3NlcnZlcl9saW5lX3dpdGhfdGltZW91dChtcywg Y29ubiwgdmVjLCAzLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTE9DS19OT1RfSEVMRCk7CiAgICAgaWYgKHJ2ICE9IEFQUl9TVUNDRVNTKSB7Ci0gICAg ICAgIG1zX2JhZF9jb25uKG1zLCBjb25uKTsKLSAgICAgICAgYXByX21lbWNhY2hlX2Rpc2FibGVf c2VydmVyKG1jLCBtcyk7CiAgICAgICAgIHJldHVybiBydjsKICAgICB9CiAKLSAgICBydiA9IGdl dF9zZXJ2ZXJfbGluZShjb25uKTsKLSAgICBpZiAocnYgIT0gQVBSX1NVQ0NFU1MpIHsKLSAgICAg ICAgbXNfYmFkX2Nvbm4obXMsIGNvbm4pOwotICAgICAgICBhcHJfbWVtY2FjaGVfZGlzYWJsZV9z ZXJ2ZXIobWMsIG1zKTsKLSAgICAgICAgcmV0dXJuIHJ2OwotICAgIH0KLQogICAgIGlmIChzdHJu Y21wKE1TX1ZBTFVFLCBjb25uLT5idWZmZXIsIE1TX1ZBTFVFX0xFTikgPT0gMCkgewogICAgICAg ICBjaGFyICpmbGFnczsKICAgICAgICAgY2hhciAqbGVuZ3RoOwpAQCAtODgzLDcgKzk3MSw2IEBA CiAgICAgYXByX21lbWNhY2hlX3NlcnZlcl90ICptczsKICAgICBhcHJfbWVtY2FjaGVfY29ubl90 ICpjb25uOwogICAgIGFwcl91aW50MzJfdCBoYXNoOwotICAgIGFwcl9zaXplX3Qgd3JpdHRlbjsK ICAgICBzdHJ1Y3QgaW92ZWMgdmVjWzNdOwogICAgIGFwcl9zaXplX3Qga2xlbiA9IHN0cmxlbihr ZXkpOwogCkBAIC05MTEsMjEgKzk5OCwxMiBAQAogICAgIHZlY1syXS5pb3ZfYmFzZSA9IGNvbm4t PmJ1ZmZlcjsKICAgICB2ZWNbMl0uaW92X2xlbiAgPSBrbGVuOwogCi0gICAgcnYgPSBhcHJfc29j a2V0X3NlbmR2KGNvbm4tPnNvY2ssIHZlYywgMywgJndyaXR0ZW4pOwotCisgICAgcnYgPSBzZW5k dl9hbmRfZ2V0X3NlcnZlcl9saW5lX3dpdGhfdGltZW91dChtcywgY29ubiwgdmVjLCAzLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTE9DS19OT1RfSEVM RCk7CiAgICAgaWYgKHJ2ICE9IEFQUl9TVUNDRVNTKSB7Ci0gICAgICAgIG1zX2JhZF9jb25uKG1z LCBjb25uKTsKLSAgICAgICAgYXByX21lbWNhY2hlX2Rpc2FibGVfc2VydmVyKG1jLCBtcyk7CiAg ICAgICAgIHJldHVybiBydjsKICAgICB9CiAKLSAgICBydiA9IGdldF9zZXJ2ZXJfbGluZShjb25u KTsKLSAgICBpZiAocnYgIT0gQVBSX1NVQ0NFU1MpIHsKLSAgICAgICAgbXNfYmFkX2Nvbm4obXMs IGNvbm4pOwotICAgICAgICBhcHJfbWVtY2FjaGVfZGlzYWJsZV9zZXJ2ZXIobWMsIG1zKTsKLSAg ICAgICAgcmV0dXJuIHJ2OwotICAgIH0KLQogICAgIGlmIChzdHJuY21wKE1TX0RFTEVURUQsIGNv bm4tPmJ1ZmZlciwgTVNfREVMRVRFRF9MRU4pID09IDApIHsKICAgICAgICAgcnYgPSBBUFJfU1VD Q0VTUzsKICAgICB9CkBAIC05NTIsNyArMTAzMCw2IEBACiAgICAgYXByX21lbWNhY2hlX3NlcnZl cl90ICptczsKICAgICBhcHJfbWVtY2FjaGVfY29ubl90ICpjb25uOwogICAgIGFwcl91aW50MzJf dCBoYXNoOwotICAgIGFwcl9zaXplX3Qgd3JpdHRlbjsKICAgICBzdHJ1Y3QgaW92ZWMgdmVjWzNd OwogICAgIGFwcl9zaXplX3Qga2xlbiA9IHN0cmxlbihrZXkpOwogCkBAIC05ODAsMjEgKzEwNTcs MTIgQEAKICAgICB2ZWNbMl0uaW92X2Jhc2UgPSBjb25uLT5idWZmZXI7CiAgICAgdmVjWzJdLmlv dl9sZW4gID0ga2xlbjsKIAotICAgIHJ2ID0gYXByX3NvY2tldF9zZW5kdihjb25uLT5zb2NrLCB2 ZWMsIDMsICZ3cml0dGVuKTsKLQorICAgIHJ2ID0gc2VuZHZfYW5kX2dldF9zZXJ2ZXJfbGluZV93 aXRoX3RpbWVvdXQobXMsIGNvbm4sIHZlYywgMywKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIExPQ0tfTk9UX0hFTEQpOwogICAgIGlmIChydiAhPSBBUFJf U1VDQ0VTUykgewotICAgICAgICBtc19iYWRfY29ubihtcywgY29ubik7Ci0gICAgICAgIGFwcl9t ZW1jYWNoZV9kaXNhYmxlX3NlcnZlcihtYywgbXMpOwogICAgICAgICByZXR1cm4gcnY7CiAgICAg fQogCi0gICAgcnYgPSBnZXRfc2VydmVyX2xpbmUoY29ubik7Ci0gICAgaWYgKHJ2ICE9IEFQUl9T VUNDRVNTKSB7Ci0gICAgICAgIG1zX2JhZF9jb25uKG1zLCBjb25uKTsKLSAgICAgICAgYXByX21l bWNhY2hlX2Rpc2FibGVfc2VydmVyKG1jLCBtcyk7Ci0gICAgICAgIHJldHVybiBydjsKLSAgICB9 Ci0KICAgICBpZiAoc3RybmNtcChNU19FUlJPUiwgY29ubi0+YnVmZmVyLCBNU19FUlJPUl9MRU4p ID09IDApIHsKICAgICAgICAgcnYgPSBBUFJfRUdFTkVSQUw7CiAgICAgfQpAQCAtMTA1MSw3ICsx MTE5LDYgQEAKIHsKICAgICBhcHJfc3RhdHVzX3QgcnY7CiAgICAgYXByX21lbWNhY2hlX2Nvbm5f dCAqY29ubjsKLSAgICBhcHJfc2l6ZV90IHdyaXR0ZW47CiAgICAgc3RydWN0IGlvdmVjIHZlY1sy XTsKIAogICAgIHJ2ID0gbXNfZmluZF9jb25uKG1zLCAmY29ubik7CkBAIC0xMDY3LDE5ICsxMTM0 LDEyIEBACiAgICAgdmVjWzFdLmlvdl9iYXNlID0gKGNoYXIqKSBNQ19FT0w7CiAgICAgdmVjWzFd Lmlvdl9sZW4gID0gTUNfRU9MX0xFTjsKIAotICAgIHJ2ID0gYXByX3NvY2tldF9zZW5kdihjb25u LT5zb2NrLCB2ZWMsIDIsICZ3cml0dGVuKTsKLQorICAgIHJ2ID0gc2VuZHZfYW5kX2dldF9zZXJ2 ZXJfbGluZV93aXRoX3RpbWVvdXQobXMsIGNvbm4sIHZlYywgMiwKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExPQ0tfTk9UX0hFTEQpOwogICAgIGlmIChy diAhPSBBUFJfU1VDQ0VTUykgewotICAgICAgICBtc19iYWRfY29ubihtcywgY29ubik7CiAgICAg ICAgIHJldHVybiBydjsKICAgICB9CiAKLSAgICBydiA9IGdldF9zZXJ2ZXJfbGluZShjb25uKTsK LSAgICBpZiAocnYgIT0gQVBSX1NVQ0NFU1MpIHsKLSAgICAgICAgbXNfYmFkX2Nvbm4obXMsIGNv bm4pOwotICAgICAgICByZXR1cm4gcnY7Ci0gICAgfQotCiAgICAgaWYgKHN0cm5jbXAoTVNfVkVS U0lPTiwgY29ubi0+YnVmZmVyLCBNU19WRVJTSU9OX0xFTikgPT0gMCkgewogICAgICAgICAqYmF0 b24gPSBhcHJfcHN0cm1lbWR1cChwLCBjb25uLT5idWZmZXIrTVNfVkVSU0lPTl9MRU4rMSwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29ubi0+YmxlbiAtIE1TX1ZFUlNJT05fTEVO IC0gMik7CkBAIC0xMDk0LDEwICsxMTU0LDkgQEAKICAgICByZXR1cm4gcnY7CiB9CiAKLWFwcl9z dGF0dXNfdCBtY192ZXJzaW9uX3BpbmcoYXByX21lbWNhY2hlX3NlcnZlcl90ICptcykKK3N0YXRp YyBhcHJfc3RhdHVzX3QgbWNfdmVyc2lvbl9waW5nX2xvY2tfaGVsZChhcHJfbWVtY2FjaGVfc2Vy dmVyX3QgKm1zKQogewogICAgIGFwcl9zdGF0dXNfdCBydjsKLSAgICBhcHJfc2l6ZV90IHdyaXR0 ZW47CiAgICAgc3RydWN0IGlvdmVjIHZlY1syXTsKICAgICBhcHJfbWVtY2FjaGVfY29ubl90ICpj b25uOwogCkBAIC0xMTE0LDE0ICsxMTczLDExIEBACiAgICAgdmVjWzFdLmlvdl9iYXNlID0gKGNo YXIqKSBNQ19FT0w7CiAgICAgdmVjWzFdLmlvdl9sZW4gID0gTUNfRU9MX0xFTjsKIAotICAgIHJ2 ID0gYXByX3NvY2tldF9zZW5kdihjb25uLT5zb2NrLCB2ZWMsIDIsICZ3cml0dGVuKTsKLQorICAg IHJ2ID0gc2VuZHZfYW5kX2dldF9zZXJ2ZXJfbGluZV93aXRoX3RpbWVvdXQobXMsIGNvbm4sIHZl YywgMiwgTE9DS19IRUxEKTsKICAgICBpZiAocnYgIT0gQVBSX1NVQ0NFU1MpIHsKLSAgICAgICAg bXNfYmFkX2Nvbm4obXMsIGNvbm4pOwogICAgICAgICByZXR1cm4gcnY7CiAgICAgfQogCi0gICAg cnYgPSBnZXRfc2VydmVyX2xpbmUoY29ubik7CiAgICAgbXNfcmVsZWFzZV9jb25uKG1zLCBjb25u KTsKICAgICByZXR1cm4gcnY7CiB9CkBAIC0xNjg3LDYgKzE3NDMsMTEgQEAKICAgICAgICAgcmV0 dXJuIHJ2OwogICAgIH0KIAorICAgIHJ2ID0gcG9sbF9zZXJ2ZXJfcmVsZWFzaW5nX2Nvbm5lY3Rp b25fb25fZmFpbHVyZShtcywgTE9DS19OT1RfSEVMRCwgY29ubik7CisgICAgaWYgKHJ2ICE9IEFQ Ul9TVUNDRVNTKSB7CisgICAgICAgIHJldHVybiBydjsKKyAgICB9CisKICAgICByZXQgPSBhcHJf cGNhbGxvYyhwLCBzaXplb2YoYXByX21lbWNhY2hlX3N0YXRzX3QpKTsKIAogICAgIGRvIHsKSW5k ZXg6IHRoaXJkX3BhcnR5L2FwcnV0aWwvYXByX21lbWNhY2hlLmgKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdGhp cmRfcGFydHkvYXBydXRpbC9hcHJfbWVtY2FjaGUuaAkocmV2aXNpb24gMjEyMSkKKysrIHRoaXJk X3BhcnR5L2FwcnV0aWwvYXByX21lbWNhY2hlLmgJKHdvcmtpbmcgY29weSkKQEAgLTU1LDYgKzU1 LDkgQEAKIC8qKiBPcGFxdWUgbWVtY2FjaGUgY2xpZW50IGNvbm5lY3Rpb24gb2JqZWN0ICovCiB0 eXBlZGVmIHN0cnVjdCBhcHJfbWVtY2FjaGVfY29ubl90IGFwcl9tZW1jYWNoZV9jb25uX3Q7CiAK Ky8qKiBtZW1jYWNoZTIgb2JqZWN0IC0tIGNvbnRhaW5zIGVhY2ggc2VydmVyIHNoYXJkICovCit0 eXBlZGVmIHN0cnVjdCBhcHJfbWVtY2FjaGVfdCBhcHJfbWVtY2FjaGVfdDsKKwogLyoqIE1lbWNh Y2hlIFNlcnZlciBJbmZvIE9iamVjdCAqLwogdHlwZWRlZiBzdHJ1Y3QgYXByX21lbWNhY2hlX3Nl cnZlcl90IGFwcl9tZW1jYWNoZV9zZXJ2ZXJfdDsKIHN0cnVjdCBhcHJfbWVtY2FjaGVfc2VydmVy X3QKQEAgLTcyLDYgKzc1LDcgQEAKICAgICBhcHJfdGhyZWFkX211dGV4X3QgKmxvY2s7CiAjZW5k aWYKICAgICBhcHJfdGltZV90IGJ0aW1lOworICAgIGFwcl9tZW1jYWNoZV90KiBtZW1jYWNoZTsK IH07CiAKIC8qIEN1c3RvbSBoYXNoIGNhbGxiYWNrIGZ1bmN0aW9uIHByb3RvdHlwZSwgdXNlciBm b3Igc2VydmVyIHNlbGVjdGlvbi4KQEAgLTgzLDggKzg3LDYgQEAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZGF0YSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgYXByX3NpemVfdCBk YXRhX2xlbik7CiAKLXR5cGVkZWYgc3RydWN0IGFwcl9tZW1jYWNoZV90IGFwcl9tZW1jYWNoZV90 OwotCiAvKiBDdXN0b20gU2VydmVyIFNlbGVjdCBjYWxsYmFjayBmdW5jdGlvbiBwcm90b3R5cGUu CiAqIEBwYXJhbSBiYXRvbiB1c2VyIHNlbGVjdGVkIGJhdG9uCiAqIEBwYXJhbSBtYyBtZW1jYWNo ZSBpbnN0YW5jZSwgdXNlIG1jLT5saXZlX3NlcnZlcnMgdG8gc2VsZWN0IGEgbm9kZQo= --e89a8f235977d79b0504cd6dd11f--