harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] APR latest release is 1.2.7, we're using 1.2.6. Should we switch?
Date Thu, 30 Nov 2006 15:17:04 GMT
On 11/30/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
>
> 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.


That's exactly right.  The corollary is that there need be no discussion
about moving to latest APR release (the title of the email chain).  Whoever
maintains this part of threading can take from APR what they think is
appropriate w/o asking dev list.  No discussion about what to do w/ mods to
APR.  Let the APR folks take the mods from Harmony if they are motivated to
do so.


+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
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message