apr_memcache_multgetp hangs forever after network hiccup

[Geoff Greer <an...@mipsisrisc.com>]

I had some problems at work with CGIs spinning. Attaching gdb gave me  
this:

(gdb) bt
#0  0x008e17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00166a86 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/ 
libpthread.so.0
#2  0x081e1cd7 in apr_reslist_acquire (reslist=0x8619860,  
resource=0xb6b7ec60) at misc/apr_reslist.c:333
#3  0x081df7d0 in ms_find_conn (ms=Variable "ms" is not available.) at  
memcache/apr_memcache.c:273
#4  0x081e0b27 in apr_memcache_multgetp (mc=0x86057c0,  
temp_pool=0x88262f0, data_pool=0x88202d8, values=0x8820318) at  
memcache/apr_memcache.c:1276
#5  0x081e8b90 in dbCache::get_mult_cachable_internal (this=0x87c27f8,  
cachename=0x81ff227 "unreaditem", cacheversion=1, start=0, end=14,  
multhandler=@0xb6b7ee30) at dbcache/dbcache.C:277
(gdb) f 2
#2  0x081e1cd7 in apr_reslist_acquire (reslist=0x8619860,  
resource=0xb6b7ec60) at misc/apr_reslist.c:333
333      misc/apr_reslist.c: No such file or directory.
         in misc/apr_reslist.c
Current language:  auto; currently c
(gdb) p reslist->timeout
$1 = 0

The resource list timeout was set to 0, so some network trouble caused  
the CGI to sit there forever. Attached is a patch to fix the problem.  
The #defined timeout of 5 seconds is fine for what I need, but it  
would good to expose it (apr_memcache_timeout_set?) for users to  
customize.

Geoff