Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180109174234.GA1627@brightrain.aerifal.cx>
Date: Tue, 9 Jan 2018 12:42:34 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 5/7] use the new lock algorithm for malloc

On Wed, Jan 03, 2018 at 02:17:12PM +0100, Jens Gustedt wrote:
> Malloc used a specialized lock implementation in many places. Now that we
> have a generic lock that has the desired properties, we should just use
> this, instead of this multitude of very similar lock mechanisms.
> ---
>  src/malloc/malloc.c | 38 +++++++++++++-------------------------
>  1 file changed, 13 insertions(+), 25 deletions(-)
> 
> diff --git a/src/malloc/malloc.c b/src/malloc/malloc.c
> index 9e05e1d6..6c667a5a 100644
> --- a/src/malloc/malloc.c
> +++ b/src/malloc/malloc.c
> @@ -13,6 +13,8 @@
>  #define inline inline __attribute__((always_inline))
>  #endif
>  
> +#include "__lock.h"
> +

Ah, I see -- maybe you deemed malloc to be the only place where
inlining for the sake of speed made sense? That's probably true.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.