This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ptmalloc2?


On May 13 23:55, Christopher Faylor wrote:
> On Thu, May 13, 2004 at 04:13:00PM -0500, Brian Ford wrote:
> >On Thu, 13 May 2004, Christopher Faylor wrote:
> >>Why does using ptmalloc buy you anything over the current scheme?
> >
> >Since I'm not very far into the port yet, I'm taking Doug Lea and
> >Wolfram Gloger's word for it, but ptmalloc was specifically designed
> >with SMP/multi-threading in mind to reduce contention.  That is the
> >assumed advantage.  I also assumed that if it was good enough for
> >glibc/Linux, then it might be good enough/better for us too.
> >
> >>You're asking if it's a good idea to use something without stating any
> >>benefits.
> >
> >I'm asking for obvious up front objections/encouragment and pointers to
> >gotchas, especially license wise since I'm not very familiar with that
> >issue (contributing ports of code you didn't write with compatable
> >licenses).
> >
> >I assumed people on this list might be familiar with different malloc
> >implimentations, and I thought I expressed my intent to attack a
> >certain specific (at least percieved) problem; thread contention.
> >
> >I'm confused about what was unclear.
> 
> You sent email saying "We're seeing thread contention so I thought I'd
> contribute a port of ptmalloc2".
> 
> The reader is left to do some inferring.  One could infer that you think
> that ptmalloc2 is better at eliminating the thread contention that you
> think you have.  One could surmise that you think that any decisions that
> glibc makes are ok for cygwin and so need no further technical review.
> In this message you mention a new name: "Wolfram Gloger", and we are
> left to conclude that he must be some kind of malloc genius whom we should
> hang our heads in shame for not knowing.
> 
> If you have a need and want to make a major change to a fundamental part
> of cygwin, don't expect that everyone will drop everything and jump on
> over to glibc sources (or google) to look around to see what you're
> talking about.  Make a technical argument for what you want and don't
> waste our time with assumptions about your perception of our familiarity
> with malloc implementations.  Don't expect us to trust either you, glibc
> developers, or Wolfram Gloger to come to correct conclusions about what
> is required for cygwin.
> [SNIP]

I'm sorry but I have to support Chris up to this point.

Brian, what exactly is the problem?  Do you have a testcase which shows
what goes wrong and perhaps even where it goes wrong?  I'm not quite sure
it's a good idea to replace an important piece of code entirely by a new
implementation (with again a bunch of unknown bugs) instead of tring to
tackle the problem in the existing code.  This should be at least the
start point.  If you have mice in your house, you don't start with replacing
the cellar.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]