Salikh Zakirov wrote:
Weldon Washburn wrote:
After reading an excellent survey (
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html)on implementing
posix-style
condition variables on windowsxp, its not clear that being dependent on
any
external posix-to-win32 wrapper is acceptable for Harmony. If this
paper is
correct, it looks rather tricky to correctly implement condition variables
on windows. My take on the whole subject is that Harmony needs to fix
and/or morph some "condition variable on win32" thingy. Its OK if the
"thingy" happens to be APR. But I would not let APR slow Harmony down. To
do condition variables per the paper, the APR code base may change a bunch.
Its unclear if the APR crowd will want to incorporate such mods. I lean
towards dumping APR.
... or just stop pretending we are using apr_thread_cond_t, while in fact
we are using completely different implementation.
I think that patched (rewritten) thread_cond.c can easily be ported
to implement hycond_t directly (besides, currently hycond_t is #defined to be
apr_thread_cond_t).
We do not need to get orthodox about "use APR" or "dump APR",
but instead just use what we need, and do not use what is not suitable.
+1
If we've patched the standard impl of apr_thread_cond_t into oblivion,
lets just be honest and use our own method.
(I'm more than happy if we wean ourselves off of the dogmatic use of
APR, and just use what makes sense for *us*)
geir
