On Apr 6, 2017 3:34 PM, "Jim Jagielski" wrote:
> On Apr 6, 2017, at 4:25 PM, Jacob Champion wrote:
>
>
> A zero or negative timeout should attempt to instantaneously acquire, and
return TIMEUP immediately if that's not possible. Treating negative
On 06.04.17 19:32 , Branko Čibej wrote:
> These are not APR headers, they're httpd headers.
Oops, thank you. My bad. I will post this question/comment in the httpd mailing
list then.
Cheers,
K. C
--
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D
/*
Thou
On Fri, Apr 7, 2017 at 1:17 AM, Branko Čibej wrote:
>
> brane@zulu:~/src/apr/build/trunk$ grep HAVE_PTHREAD_CONDATTR_SETPSHARED
> ./include/arch/unix/apr_private.h
> #define HAVE_PTHREAD_CONDATTR_SETPSHARED 1
>
>
> Looks good?
Yes, looks good, the condvar fallback for
On 06.04.2017 22:00, Helmut K. C. Tessarek wrote:
> There is a bug in how APR and APR-util are distributed.
>
> Some of the typical autotools defines made it into the current packages
> and they interfere with one's own build process:
>
> one example (there are 5 different occurrences):
>
> In
On 06.04.2017 21:05, Yann Ylavic wrote:
> On Thu, Apr 6, 2017 at 9:01 PM, Branko Čibej wrote:
>> On 06.04.2017 20:49, Yann Ylavic wrote:
>>> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski wrote:
apr-trunk (r1790379):
% ./testall -v testprocmutex
> On Apr 6, 2017, at 4:25 PM, Jacob Champion wrote:
>
>
> A zero or negative timeout should attempt to instantaneously acquire, and
> return TIMEUP immediately if that's not possible. Treating negative values
> the same way as zero allows client code to handle
On Wed, Apr 5, 2017 at 7:45 PM, Jim Jagielski wrote:
In fact, that goes for all, really. All *.timedacquire() impl
should return APR_TIMEUP for any timeout < 0. Instead we
try to acquire which is against the whole ABI guarantee.
If you're trying to match the pthreads API,
There is a bug in how APR and APR-util are distributed.
Some of the typical autotools defines made it into the current packages
and they interfere with one's own build process:
one example (there are 5 different occurrences):
In file included from /usr/local/apache/include/ap_config.h:138:0,
As of HEAD on apr-trunk, all tests pass fine on OSX.
Plus:
./include/arch/unix/apr_private.h:#define HAVE_PTHREAD_CONDATTR_SETPSHARED 1
So I'm +1 for backporting to 1.6!
> On Apr 6, 2017, at 2:49 PM, Yann Ylavic wrote:
>
> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski
On Thu, Apr 6, 2017 at 9:01 PM, Branko Čibej wrote:
> On 06.04.2017 20:49, Yann Ylavic wrote:
>> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski wrote:
>>> apr-trunk (r1790379):
>>> % ./testall -v testprocmutex
>>> testprocmutex : -Line 189: Locks
On 06.04.2017 20:49, Yann Ylavic wrote:
> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski wrote:
>> apr-trunk (r1790379):
>> % ./testall -v testprocmutex
>> testprocmutex : -Line 189: Locks don't appear to work with timedlock
>> -flock_timedlock() not implemented,/Line
On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski wrote:
> apr-trunk (r1790379):
> % ./testall -v testprocmutex
> testprocmutex : -Line 189: Locks don't appear to work with timedlock
> -flock_timedlock() not implemented,/Line 189: Locks don't appear to work
> with
apr-trunk (r1790379):
% ./testall -v testprocmutex
testprocmutex : -Line 189: Locks don't appear to work with timedlock
-flock_timedlock() not implemented,/Line 189: Locks don't appear to work with
timedlock
-Line 189: Locks don't appear to work with timedlock
-fcntl_timedlock()
13 matches
Mail list logo