This is the mail archive of the mailing list for the glibc 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: [PATCH] malloc: add locking to thread cache

On Wed, Jan 27, 2016 at 10:05:33AM +0000, Szabolcs Nagy wrote:
> portable code does not need the fix, but all users
> of the api are affected by the overhead of the fix.

Sorry, but you have no idea what you are talking about.  The overhead of
the fix is _negative_.  Users _want_ to be affected.

The reason why free() is not signalsafe is that it spins on an
arena-lock.  If the same thread already holds that lock, you have a
classic deadlock.  By not spinning on the lock you make code run faster.
You also fix the signal-induced deadlock.

Ok, for thread-cache there is some overhead.  Without signal-safety you
wouldn't need a lock for the thread-cache at all.  But here I call
bullshit again, because I had the same concerns.  Then I measured and
could not demonstrate any performance impact.

"If you cannot measure it, it does not exist."

You might disagree philosophically, but if an engineers goes out of his
way to measure a certain effect and finds nothing, that effect hardly
matters in any practical way.


Only children believe that ideas are simply born.  Usually two other
ideas have sex.
-- Jon Gnarr

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