After doing some additional research, I think that the
current implementation of NOT allowing duplicates (in
APR 1.5/1.6) is BROKEN. In trunk this is determined by
a flag w/ the insert statement, but the default *should*
be to allow dups.
As such, I'd like to adjust 1.5/1.6 to the correct and,
afa
Plus, the way we do it in trunk breaks the skiplist stability
requirement, so that needs to be fixed as well.
> On Mar 5, 2015, at 11:19 AM, Jim Jagielski wrote:
>
> After doing some additional research, I think that the
> current implementation of NOT allowing duplicates (in
>
No, we didn't. But the current behavior is broken, so if people
are expecting our skiplists to act like "real" skiplists, it will
fail. I think fixing broken should be allowed...
> On Mar 5, 2015, at 11:29 AM, Ruediger Pluem wrote:
>
>
>
> On 03/05/2015 05:19 PM,
Subj sez it all.
> On Mar 5, 2015, at 12:36 PM, Yann Ylavic wrote:
>
> On Thu, Mar 5, 2015 at 5:51 PM, wrote:
>> Author: jim
>> Date: Thu Mar 5 16:51:39 2015
>> New Revision: 1664406
>>
>> URL: http://svn.apache.org/r1664406
>> Log:
>> FIX: Skiplists should allow for dups by default. Also, when added, dups
>
> On Mar 7, 2015, at 2:30 AM, William A. Rowe Jr. wrote:
>
> On Thu, 5 Mar 2015 11:19:40 -0500
> Jim Jagielski wrote:
>
>> After doing some additional research, I think that the
>> current implementation of NOT allowing duplicates (in
>> APR 1.5/1.6) is BROKE
> On Mar 6, 2015, at 8:29 PM, yla...@apache.org wrote:
>
> Author: ylavic
> Date: Sat Mar 7 01:29:20 2015
> New Revision: 1664775
>
> URL: http://svn.apache.org/r1664775
> Log:
> skiplist:
>
> Generalize the internal stack structure as a queue (FIFO), and use it for the
> spare nodes (instead
Fixed in r1664911, 1664912, 1664913
>
> No, it's a design error. There's not much helping that... once it
> ships, that's our implementation. Might caution us to provide more
> careful code review before n.n.0 releases on new features.
S if apr_snprintf("%d" were to, on every 50th int, print
it out in decimal form, that
> On Mar 12, 2015, at 1:36 PM, Jim Jagielski wrote:
>
>>
>> No, it's a design error. There's not much helping that... once it
>> ships, that's our implementation. Might caution us to provide more
>> careful code review before n.n.0 releases on ne
>
> S if apr_snprintf("%d" were to, on every 50th int, print
> it out in decimal form, that would be a "design error"? :)
>
> That's a terrible analogy :)
>
Yeah, I agree.
>
> If so, how can we call it a "skiplist" which has a set of compliant
> expectations? It's not a skiplist impl
> On Mar 13, 2015, at 8:04 AM, Yann Ylavic wrote:
>
> It seems that the implementation is not that broken actually.
>
> One can still have the add semantic with insert() in 1.5.x by using
> the appropriate compare function and apr_skiplist_insert_compare(),
> that is, a function that does not r
Hmmm... seeing a regression on OSX 10.10.3 w/ Xcode 6.3.1:
% ./testall -v testpoll
testpoll: /Line 816: expected <0>, but saw <4>
FAILED 1 of 23
Failed Tests Total FailFailed %
===
testpoll
Under FreeBSD 10, I see no issue w/ testpoll.
So it's looking like an OSX issue and not kqueue per-se.
> On Apr 28, 2015, at 8:40 AM, Jeff Trawick wrote:
>
> On 04/28/2015 08:38 AM, Jim Jagielski wrote:
>> Hmmm... seeing a regression on OSX 10.10.3 w/ Xcode 6.3.1:
>
Looks like OSX is returning EINTR?
[EINTR]A signal was delivered before the timeout expired and
before any events were placed
on the kqueue for return.
> On Apr 28, 2015, at 8:38 AM, Jim Jagielski wrote:
>
> Hmmm... seeing a regression on OS
Could it be that we are seeing a race condition... that the
data isn't available by the time we wakeup and poll?
> On Apr 28, 2015, at 9:02 AM, Jeff Trawick wrote:
>
> On 04/28/2015 08:52 AM, Jim Jagielski wrote:
>> Under FreeBSD 10, I see no issue w/ testpoll.
>>
Yeah, that's it, at least from what I can see. If I add a sleep(1)
right after the send_msg, we pass.
> On Apr 28, 2015, at 9:10 AM, Jim Jagielski wrote:
>
> Could it be that we are seeing a race condition... that the
> data isn't available by the time we wakeup and poll?
++1
Finishing my others tests as we speak :)
> On Apr 28, 2015, at 9:19 AM, Jeff Trawick wrote:
>
> On 04/28/2015 09:12 AM, Jim Jagielski wrote:
>> Yeah, that's it, at least from what I can see. If I add a sleep(1)
>> right after the send_msg, we pass.
>
> T
OK...
+1: OSX 10.10.3 / Xcode 6.3.1
FreeBSD 10.1 x64
CentOS 6 and 7, x64
Thx for RMing!
The docs cleanup has broken a TON of links... Do a search on any
APR function and chances are good that results will refer
to the now-nonexistant 1.3/1.4 urls.
> On Aug 27, 2015, at 7:53 PM, Noel Butler wrote:
>
>
>> That's why I want us to extend cmake to do the unix build as well.
>>
>>
>>
> The biggest bitch I here from *nix/bsd system admins everywhere is cmake,
> the largest bitch is people know how to use --with-foo --with-bar now after
What issues?
I have 10.10.5 and Xcode7 and so far, no issues.
> On Sep 21, 2015, at 11:03 PM, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> I tried building on OSX but was unsuccessful. I'd like to inform the
> devs of the issue, and provide config.log and the compiler error.
>
> Apache's APR pa
Haven't looked at the actual bug but yet, in general, we appreciate
it when people send in patches that fix bugs or errors in our code
instead of simply forking off those changes.
Apache tries to work a little bit differently than the current buzz
about forking and working in isolation; we instead
I've been keen on libmill, which provides a golang-like
goroutine library. It seems that such functionality would
be cool for APR and APR-based apps (like serf and httpd).
Then I started thinking: Lua also has a great coroutine impl
and it is also MIT licensed and might be easier to fold
into APR.
> On Sep 26, 2015, at 3:11 PM, Branko Čibej wrote:
>
> On 26.09.2015 19:10, Jim Jagielski wrote:
>> I've been keen on libmill, which provides a golang-like
>> goroutine library. It seems that such functionality would
>> be cool for APR and APR-based apps (lik
If we are serious about having a serious update to APR, I
would recommend that we use more up-to-date data structures,
patterns and algorithms than those in apr1. For example,
Greg's pocore mini lib is an example of the types of improvements
we should consider.
> On Nov 20, 2015, at 1:31 PM, Willi
On Fri, Nov 20, 2015 at 11:14 PM, William A Rowe Jr
> wrote:
> > On Fri, Nov 20, 2015 at 2:55 PM, Yann Ylavic wrote:
> >>
> >> On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski wrote:
> >> > If we are serious about having a serious update to APR, I
>
> On Nov 21, 2015, at 10:39 AM, Yann Ylavic wrote:
>
> On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej wrote:
>> On 21.11.2015 09:31, Graham Leggett wrote:
>>> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr wrote:
>>>
Any objections to picking this up for APR 1.next/2.0?
It see
Should we then adjust docs and usage to remove the "greater/less than"
criteria and just say equal strings return 0 and non 0 means that
the strings don't compare/are different?
> On Nov 23, 2015, at 10:19 AM, William A Rowe Jr wrote:
>
> On Mon, Nov 23, 2015 at 2:11 AM, Branko Čibej wrote:
>
In a library that has:
apr_pstrdup()
apr_pstrndup()
apr_pstrmemdup()
and apr_pstrmemdup() and apr_pstrndup() are functionally
the same, as well as:
apr_strnatcasecmp()
apr_strnatcmp()
neither of which use an 'n' variable to determine string
size, yet is c
> On Nov 26, 2015, at 8:49 PM, Branko Čibej wrote:
>
> In any case — I don't think anyone over at dev@s.a.o would object to APR
> including those functions. We actually have a number of other, heh,
> improvements on APR that we could "donate"; we just never really got
> around to producing the n
> On Nov 27, 2015, at 2:15 PM, Branko Čibej wrote:
>
> On 27.11.2015 15:59, Jim Jagielski wrote:
>>> On Nov 26, 2015, at 8:49 PM, Branko Čibej wrote:
>>>
>>> In any case — I don't think anyone over at dev@s.a.o would object to APR
>>> inclu
Any updates on this??
I'm assuming that the 'new in 1.6' refers to APR 1.6...
In which case, I'm not sure what the Warning for apr_cstr_strtoui64()
refers to, version-wise.
> On Jan 26, 2016, at 3:58 PM, William A Rowe Jr wrote:
>
> Sorry, meant to attach something legible...
> Apache Portable Runtime
> • Main
Also, I see apr_cstr_casecmp() but not a case insensitive version... ??
> On Jan 26, 2016, at 3:58 PM, William A Rowe Jr wrote:
>
> Sorry, meant to attach something legible...
> Apache Portable Runtime
> • Main Page
> • Related Pages
> • Modules
> • Namespaces
> • D
> On Jan 27, 2016, at 4:44 AM, Branko Čibej wrote:
>
>
> Hmph, it's concise, not confusing. Subversion's APIs expect all strings
> to be encoded in UTF-8, so the docstring can't just say
> "case-insensitive" because that would be extremely misleading in that
> context.
>
> APR makes no promise
FYI:
https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
I haven't upgraded yet, so can't confirm, but something we may
need to address if Apple doesn't fix.
it.
> On Oct 31, 2016, at 10:15 AM, Graham Leggett wrote:
>
> On 31 Oct 2016, at 3:43 PM, Jim Jagielski wrote:
>
>> It would, but that would mean even more of a APR dependency
>> and a wait until the next release of APR and etc, etc, etc...
>> Basically, APR move
The current work-in-progress, not yet APR-ized is at:
https://github.com/jimjag/credis
> On Oct 31, 2016, at 11:49 AM, Graham Leggett wrote:
>
> On 31 Oct 2016, at 5:05 PM, Jim Jagielski wrote:
>
>> Moving to APR:
>>
>> Query: Think it would be wo
OK, so my plan is to start pulling the relevant bits out of Credis for
use in apr_redis. I was thinking initially about maybe just using the
library, but for parity w/ apr_memcache, that doesn't make sense.
Here's the rub: I'd prefer not having to do both the 1.6 and 2.0
"ports" at the same time;
) would be easier but maybe for parity
I should continue w/ the vecs.
Also, unless people have an issue, I prefer using the "telnet"
method for the client (ala Credis) rather than the more cumbersome
method.
> On Nov 2, 2016, at 9:45 AM, Graham Leggett wrote:
>
> On 02 Nov 20
> On Nov 2, 2016, at 11:01 AM, Jim Jagielski wrote:
>
>
> Also, unless people have an issue, I prefer using the "telnet"
> method for the client (ala Credis) rather than the more cumbersome
> method.
>
Skip that... Looks like the standard RESP way is quicker, so I'll
use that.
HEAD of the 1.6.x apu branch now includes a impl of apr_redis,
with "complete" parity w/ apr_memcache as well as a test-suite.
Compiles cleanly and passes all tests.
Please check it out.
Please note that apr_redis is now also in apr-2.0/trunk as
well. I went ahead and added STAT capability for apr_memcache. :)
I'm thinking that trying to do a 1.6 release in Jan 2017 makes
some sense. It would help in some httpd things. As far as
I can tell, everyone is in agreement, but wanted clarity to
make sure.
thx.
Occasionally, I get:
testpoll: /Line 816: expected <0>, but saw <4>
Anyway I could easily see what test, exactly, is failing?
./testall -v testpoll does nil.
I didn't realize it referred to the actual line number in the
source file... How dumb :)
This is on OSX so I'm getting EINTR.
Weird.
> On Jan 10, 2017, at 10:20 AM, Rainer Jung wrote:
>
> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>> Occasionally, I get:
>>
On my system, poll works.
> On Jan 10, 2017, at 3:15 PM, William A Rowe Jr wrote:
>
> Hmmm... I knew this sounded familiar...
>
> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>
> On Tue, Jan 10, 2017 at 9:46 AM, Jim Jagielski wrote:
>> I di
_INT_EQUAL(tc, 1, num);
>
> So the lingering question is whether this is a general unix implementation bug
> or specific to OSX behavior.
>
>
>
> On Wed, Jan 11, 2017 at 7:22 AM, Jim Jagielski wrote:
>>
>> On my system, poll works.
>>
>>
The below got me thinking...
Right now, the pool allocator mutex is only used when, well,
allocator_alloc() is called, which means that sometimes
apr_palloc(), for example, can be thread-safeish and sometimes
not, depending on whether or not the active node has enough
space.
For 1.6 and later, it
> On Feb 20, 2017, at 9:51 AM, Stefan Eissing
> wrote:
>
>>
>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski :
>>
>> The below got me thinking...
>>
>> Right now, the pool allocator mutex is only used when, well,
>> allocator_alloc() is call
Again, this would ONLY happen if the underlying allocator has
a mutex!
> On Feb 20, 2017, at 10:06 AM, Branko Čibej wrote:
>
> On 20.02.2017 15:55, Jim Jagielski wrote:
>>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing
>>> wrote:
>>>
>>>&
Not with apr_palloc() or anything that calls apr_palloc (eg apr_pcalloc,
et.al...)
> On Feb 20, 2017, at 10:15 AM, Stefan Eissing
> wrote:
>
>>
>> Am 20.02.2017 um 16:08 schrieb Jim Jagielski :
>>
>> Again, this would ONLY happen if the underlying allocat
Again, I am only talking about those in which the allocator
has a pool... The allocator. Via apr_allocator_mutex_set().
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
> On 20.02.2017 16:08, Jim Jagielski wrote:
>> Again, this would ONLY happen if the underlying allocator
I mean, of course, "has a *mutex*"
> On Feb 20, 2017, at 10:39 AM, Jim Jagielski wrote:
>
> Again, I am only talking about those in which the allocator
> has a pool... The allocator. Via apr_allocator_mutex_set().
>
>> On Feb 20, 2017, at 10:26 AM, Branko Čibej
You are confusing pool mutexes with allocator mutexes...
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
> On 20.02.2017 16:08, Jim Jagielski wrote:
>> Again, this would ONLY happen if the underlying allocator has
>> a mutex!
>
> Sure, but you need an allocat
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
>
> APR pools were designed with the assumption that separate threads will
> always use separate pools whenever concurrent allocations are possible.
> This assumption happens to fit pretty well with the
> server/worker/thread-pool architectu
Please READ apr_pools.c... Search for '->mutex'
> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>
> On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski wrote:
>> You are confusing pool mutexes with allocator mutexes...
>
> I'm not sure to understand,
apr_pool_create_ex_debug(), yes.
> On Feb 20, 2017, at 11:00 AM, Yann Ylavic wrote:
>
> Well, this is for debug mode only I guess.
>
> On Mon, Feb 20, 2017 at 4:59 PM, Jim Jagielski wrote:
>> Please READ apr_pools.c... Search for '->mutex'
>>
>&
> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>
>
> So as Brane says, if one sets a mutex to the allocator of a pool
> because (s)he wants pool_create/destroy() to be thread-safe, it does
> not necessarily wants the same for palloc() and friends (e.g. the pool
> is used by a single thread)
>
> It could be done, but who would use it that way?
>
I think the non-thread safety of pools requires that each
person/developer implement their own locking esp around areas
where they might not even understand that there is cross-thread
issues. Thinking about 1.6 and especially apr 2.0, it m
Fair enuff... sounds like thread safe pools aren't something
people are interested in, so I won't worry about it :)
thx for the discussion!
This really belongs in dev@apr... Adding it now.
If we are *really* drastically changing this core aspect of
pool allocation, we should reconsider my thoughts related to
more granular mutex related to anytime we alloc from a
pool to allow for, if required/desired, full thread safety
not just when
> On Mar 30, 2017, at 10:21 PM, William A Rowe Jr wrote:
>
>
> SYSVSEM > PTHREAD in the code logic, so we are still using
> sysv semaphores with all their defects over the choice of pthread
> mutexes where both are supported on Linux.
>
Which is faster?
Reading the configure.in file, it looks like we are due
for some updates for the 21st century:
# See which lock mechanism we'll select by default on this system.
# The last APR_DECIDE to execute sets the default.
# At this stage, we match the ordering in Apache 1.3
# which is (highest to lowest):
Nobody has added it yet in 1.6+
I've no idea what platforms are supported/implemented...
> On Mar 31, 2017, at 11:49 AM, Nick Kew wrote:
>
> Just (finally) got the toolchain up&running on the new macbook[1], so I’m
> testing there. Getting a failure in testprocmutex: there is no timedlock.
>
I *think* it's just supported right now for platforms that use pthread mutexes
> On Mar 31, 2017, at 12:27 PM, Jim Jagielski wrote:
>
> Nobody has added it yet in 1.6+
>
> I've no idea what platforms are supported/implemented...
>
>> On Mar 31, 2017, at 11:4
> On Apr 1, 2017, at 4:54 AM, Yann Ylavic wrote:
>
> On Fri, Mar 31, 2017 at 5:49 PM, Nick Kew wrote:
>> Just (finally) got the toolchain up&running on the new macbook[1], so I’m
>> testing there. Getting a failure in testprocmutex: there is no timedlock.
>>
>> ./testall -v testprocmutex
>> t
Using:
https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c
under OSX/macOS, pthread_mutex_lock is much quicker. Which makes
sense since sysv sems and posix sems do much more than simply
"lock"
Of course, it depends on the number of threads, natch...
> On Apr 3, 2017, at 2:07 PM, Jim Jagielski wrote:
>
> Using:
>
>https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c
>
> under OSX/macOS, pthread_mutex_lock is much quicker. Which makes
> s
Considering the sad affair w/ pthread on OSX, I would
recommend we stay w/ using sems.
It looks like we can emulate it via:
https://github.com/tinycthread/tinycthread/commit/1e8f9bba87959331e616d279dc54676e3a592799
pthread_cond_timedwait() is available under OSX but neither
PTHREAD_CONDATTR_SETPSHARED or pthread_condattr_setpshared are.
Here's a version we can use for any that lack a real pthread_mutex_timedlock():
/*
* A pthread_mutex_timedlock() impl for OSX/macOS, which lacks the
* real thing.
* NOTE:
I think that "issue" is that all such options exist on all
our (modern) platforms and we don't adjust them for specific
OSs... We prefer sysv sems and pthread mutexes.
> On Apr 4, 2017, at 6:27 AM, Nick Kew wrote:
>
> On Tue, 2017-04-04 at 10:07 +0200, Stefan Sperling wrote:
>> For APR 1.5.2 on
OK, I think I'm done with creating alternate timed implementation
for all platforms that lack them...
https://svn.apache.org/viewvc/apr/apr/branches/1.6.x/locks/unix/misc.c?revision=1790156&view=markup
> On Apr 4, 2017, at 4:29 PM, Yann Ylavic wrote:
>
>
> I'm not a big fan of the "sleep" fallback implementation.
>
Feel free to replace it with something better.
Agreed. BTW check out https://github.com/gbrault/picoc/issues/145
iirc, that is like fdatasync...
however, if someone has a test-case for me, I can run it.
> On Apr 5, 2017, at 6:40 AM, Branko Čibej wrote:
>
> On 04.04.2017 01:03, Jim Jagielski wrote:
>> pthread_cond_timedwait() is available under OSX but neither
>> PTHREAD_C
> On Apr 5, 2017, at 6:42 AM, Branko Čibej wrote:
>
> On 05.04.2017 12:39, Yann Ylavic wrote:
>> On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej wrote:
>>> On 05.04.2017 12:19, Yann Ylavic wrote:
>>>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski wrote:
>
We *could* consider using macOS native for everything...
Ugg.
> On Apr 5, 2017, at 6:39 AM, Yann Ylavic wrote:
>
>
> Agreed, there seems to be few (if any) alternatives, though, but:
> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended.
> Should we make it explicit with ENOTIMPL?
>
Maybe we should reconsider the whole idea of timedlocks
Hmmm Looking over the timed stuff, it seems that semtimedop()
is used incorrectly.
For both pthread_mutex_timedlock() and sem_timedwait(), the
timeout variable is the actual wallclock time that the wait
expires (eg: now+5mins). But, from what I can read about semtimedop(), its
timeout really i
ysV and/or Posix versions?
> On Apr 5, 2017, at 9:11 AM, William A Rowe Jr wrote:
>
> On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski wrote:
>>
>>> On Apr 5, 2017, at 6:39 AM, Yann Ylavic wrote:
>>>
>>>
>>> Agreed, there seems to be few
gh.
> On Apr 5, 2017, at 10:25 AM, Branko Čibej wrote:
>
> On 05.04.2017 14:16, Jim Jagielski wrote:
>> Hmmm Looking over the timed stuff, it seems that semtimedop()
>> is used incorrectly.
>>
>> For both pthread_mutex_timedlock() and sem_timedwait(), the
This does not seem correct at all... Why are we calling
proc_mutex_sysv_tryacquire(mutex)??
> On Apr 5, 2017, at 12:24 PM, yla...@apache.org wrote:
>
> Author: ylavic
> Date: Wed Apr 5 16:24:00 2017
> New Revision: 1790296
>
> URL: http://svn.apache.org/viewvc?rev=1790296&view=rev
> Log:
> Foll
r 5, 2017, at 1:06 PM, Yann Ylavic wrote:
>
> On Wed, Apr 5, 2017 at 6:57 PM, Jim Jagielski wrote:
>> This does not seem correct at all... Why are we calling
>> proc_mutex_sysv_tryacquire(mutex)??
>
> Because the user asked for an absolute timeout in the past, so we give
> it a non-blocking try still...
If the timeout has expired, shouldn't we return APR_TIMEUP?
> On Apr 5, 2017, at 1:25 PM, Yann Ylavic wrote:
>
> On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski wrote:
>> Your log is:
>>
>> Follow up to r1667900: semtimedop() should be passed a relative timeo
> On Apr 5, 2017, at 1:28 PM, Nick Kew wrote:
>
> On Wed, 5 Apr 2017 10:53:30 -0500
> William A Rowe Jr wrote:
>
Howbout a --with-experimental-timedlocks config option ?
>>>
>>> +1
>>>
>>> although anyone toggling an -experimental flag is expected
>>> to understand their resulting apr b
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.
> On Apr 5, 2017, at 1:37 PM, Jim Jagielski wrote:
>
> If the timeout has expired, shouldn't we
> On Apr 5, 2017, at 2:03 PM, Yann Ylavic wrote:
>
> 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 a
> On Apr 5, 2017, at 2:22 PM, Yann Ylavic wrote:
>
>
> My reasoning is rather that we implement a generic pshared condvar
> solution (like we do for thread-mutexes), and if it does not work on
> OSX (because for some reasons their condvar does not work as
> advertised or in any sane manner), we
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() no
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 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 values
> the same way as zero allows client code to handle interval calculations in a
s bad API. We are creating these from scratch, not adding additional
functionality to something that already exists. :/
> On Apr 7, 2017, at 4:21 AM, Yann Ylavic wrote:
>
> On Fri, Apr 7, 2017 at 2:28 AM, William A Rowe Jr wrote:
>> On Apr 6, 2017 3:34 PM, "Jim Jagielski"
New error:
/bin/sh /Users/jim/src/asf/code/dev/apr-trunk/libtool --silent --mode=compile
gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
-DDARWIN_10 -I../include -I./../include -I/usr/local//include -o
testlockperf.lo -c testlockperf.c && touch testlockperf.lo
testlockpe
You are assuming that the dev directly sets the timeout... what if it
is calculated and somehow the calc'd time is negative. To me
that means that it's "too late" and the expected result would
be a timeout, instead they would wait forever. This seems non
intuitive to me.
Fixed as of r1790546
> On Apr 7, 2017, at 8:39 AM, Jim Jagielski wrote:
>
> New error:
>
> /bin/sh /Users/jim/src/asf/code/dev/apr-trunk/libtool --silent --mode=compile
> gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
> -DDARWIN_10 -I../include
> On Apr 7, 2017, at 9:53 AM, Branko Čibej wrote:
>
> On 07.04.2017 14:38, Jim Jagielski wrote:
>> You are assuming that the dev directly sets the timeout... what if it
>> is calculated and somehow the calc'd time is negative. To me
>> that means that it'
+1... Let's make it so.
301 - 400 of 727 matches
Mail list logo
