I have not get any response.
Assuming that silence was caused by the long vacation, resending in hope
to get some response.
Salikh Zakirov wrote:
> the current implementation of apr_thread_cond_signal() on Windows
> has a deficiency: it may lose several concurrent or sequential
> signal() calls if more than one thread is waiting on a condition
> variable, because there is no count of the number of signal() calls,
> and only one woken up thread will really come out of the loop.
> As far as I can see, APR condition variables are meant as a portable
> replacement for pthread condition variable, however, the lost signal()
> behaviour is not compliant with pthread_cond_signal() specification :
> The pthread_cond_signal() function shall unblock at least one of the
> threads that are blocked
on the specified condition variable cond
> (if any threads are blocked on cond).
> Unfortunately, neither compliance nor defiance to this requirement is specified
> in APR manual, so I do not know if it is intentional or not.
> Can any of APR developers clarify their position?
> DRLVM  is using APR as its porting layer, however, due to the lost signal()
> issue it is forced to use its own implementation of conditional variables,
> currently arranged as an APR patch  (not really a patch, but a couple of
> files replaced).
> I am not the original author of the mentioned code, so I cannot submit it
> for inclusion into APR directly, however, the code is available from Apache
> Harmony repository licensed under AL2, and I know and can contact original
> author, though he has low motivation on submitting the patch himself.
I've submitted APR bug 41243  to track this issue.
> Can this fix be included into APR?
>  http://www.unix.org/single_unix_specification/
, pthread_cond_signal() page
>  http://harmony.apache.org/subcomponents/drlvm/index.html
>  http://issues.apache.org/bugzilla/show_bug.cgi?id=41243