On Tue, Oct 4, 2016 at 4:30 PM, Nicolai Hähnle wrote:
> On 30.09.2016 15:47, Marek Olšák wrote:
>>
>> On Fri, Sep 30, 2016 at 3:08 PM, Bas Nieuwenhuizen
>> wrote:
>>>
>>> On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák wrote:
intptr_t reads and writes aren't atomic. p_atomic_set and
On 30.09.2016 15:47, Marek Olšák wrote:
On Fri, Sep 30, 2016 at 3:08 PM, Bas Nieuwenhuizen
wrote:
On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák wrote:
intptr_t reads and writes aren't atomic. p_atomic_set and
p_atomic_read functions don't do anything for atomicity. See:
#define p_atomic_set(_
On Fri, Sep 30, 2016 at 3:08 PM, Bas Nieuwenhuizen
wrote:
> On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák wrote:
>> intptr_t reads and writes aren't atomic. p_atomic_set and
>> p_atomic_read functions don't do anything for atomicity. See:
>>
>> #define p_atomic_set(_v, _i) (*(_v) = (_i))
>> #defin
On Fri, Sep 30, 2016 at 2:13 PM, Marek Olšák wrote:
> intptr_t reads and writes aren't atomic. p_atomic_set and
> p_atomic_read functions don't do anything for atomicity. See:
>
> #define p_atomic_set(_v, _i) (*(_v) = (_i))
> #define p_atomic_read(_v) (*(_v))
That implementation seems bogus to me
intptr_t reads and writes aren't atomic. p_atomic_set and
p_atomic_read functions don't do anything for atomicity. See:
#define p_atomic_set(_v, _i) (*(_v) = (_i))
#define p_atomic_read(_v) (*(_v))
Marek
On Wed, Sep 28, 2016 at 9:47 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This is
From: Nicolai Hähnle
This is basically a re-write of the slab allocator into a design where
multiple child pools are linked to a parent pool. The intention is that
every (GL, pipe) context has its own child pool, while the corresponding
parent pool is held by the winsys or screen, or possibly the
