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][threading] comments on Harmony-3288
Date Mon, 05 Mar 2007 16:04:48 GMT
On 3/5/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> On Mar 5, 2007, at 6:14 AM, Peter Novodvorsky wrote:
>
> > I fully agree with Weldon, I only want to notice that better
> > implementation would be not #ifdef'ing platform dependent lines, but
> > implementing hymutex/hyconds with platform dependent synchronization
> > primitives as separate files for windows and linux and then using them
> > for implementing threads synchronization. This way we will recreate
> > parts of APR, but it's not a problem, because we have different
> > focuses (APR authors focus on Apache HTTPD in the end).
>
> I think I agree with all of you.  I was fairly skeptical about APR
> from the very beginning, noting that we have a set of requirements
> that's different than the original customer for APR.
>
> Glad to see this moving forward this way.


Agreed.  This is finally going the right direction.  I would caution that we
should be careful of the performance impact of replacing #ifdefs with
call/returns.  My guess is that this will not slow down things.  In any
case, we need to measure.

geir
>
> >
> > Peter.
> >
> > On 3/5/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> >> This JIRA does not specifically state the high-level motivation.
> >> It would
> >> be a good idea to discuss the motivation on the dev list so that
> >> Harmony
> >> priorities are clearly set.  I throw the following observations
> >> onto the
> >> list to get the conversation going.
> >>
> >> I think a valid motivation for H3288 is basic threading subsystem
> >> stability.  I agree with the observation that Apache Portable
> >> Runtime (APR)
> >> adds much confusion and probably even bugs to the threading
> >> model.   It
> >> would be good to reduce the amount of APR code where possible.
> >> Even if this
> >> means cluttering the native C code with "#ifdef LINUX.... #elseif
> >> WINDOWS...#endif".
> >>
> >> Bottom line:  I think Harmony-3288 is attacking the correct
> >> problem.  It
> >> looks like it is going the right direction.  I have not looked at
> >> 3288 real
> >> close thus I don't know yet if 3288 is ready for commit.
> >>
> >> --
> >> Weldon Washburn
> >> Intel Enterprise Solutions Software Division
> >>
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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