harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][threading] comments on Harmony-3288
Date Tue, 06 Mar 2007 11:29:59 GMT
Agree. This is a good move. I had the same feeling during GCv5
development, so GCv5 was designed not to use APR at all for its system
related operations, but use a wrapper to work around. Looks like it is
a good design decision.

Thanks,
xiaofeng


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

Mime
View raw message