[PATCH wayland v4 08/11] client: Replace the singleton zombie with bespoke zombies

Derek Foreman derekf at osg.samsung.com
Wed Jan 10 17:03:03 UTC 2018


On 2018-01-09 09:24 AM, Daniel Stone wrote:
> Hi,
> 
> On 3 January 2018 at 22:25, Derek Foreman <derekf at osg.samsung.com> wrote:
>> On 2017-12-28 01:53 PM, Daniel Stone wrote:
>>> @@ -434,10 +499,14 @@ proxy_destroy(struct wl_proxy *proxy)
>>>          if (proxy->flags & WL_PROXY_FLAG_ID_DELETED) {
>>>                  wl_map_remove(&proxy->display->objects, proxy->object.id);
>>>          } else if (proxy->object.id < WL_SERVER_ID_START) {
>>> +               struct wl_zombie *zombie = prepare_zombie(proxy);
>>
>>
>> I think we discussed this on irc and I said this patch was ok, but I missed
>> this change...
>>
>> prepare_zombie(proxy) should probably only be called from wl_proxy_create
>> and create_for_id - calling it in the destroy path results in a malloc()
>> call during deleting.
>>
>> Should the malloc() fail and we can't actually allocate the zombie at during
>> deletion we're going to have a problem.
> 
> Hm, yes. On the other hand, if we can't allocate the zombie object,
> then we probably won't be able to allocate the closure when
> demarshaling the events either?

I suppose since OOM situations can be ephemeral this isn't universally 
true, but I guess in situations like that we're going to fall apart 
rather soon after anyway.

> The other thing I started doing before this move, was just allocating
> zombie on the end of the wl_proxy so we only have one allocation and
> free. It does mean that proxies will consume more memory when undead,
> I suppose. I don't have strong feelings either way, so am happy to
> with any of those three ...

I'm not really tied to any specific implementation method.  That way 
would be fine with me too if you prefer it.  I don't think the memory 
increase will be significant.

For reference,
https://lists.freedesktop.org/archives/wayland-devel/2017-April/033877.html

Was where Pekka suggested the up-front allocation to avoid problems in 
low memory conditions.

I suspect 100% of the software I work on on a daily basis will explode 
in completely unpredictable and undiagnosable ways in response to a 
malloc() failure anyway, so you can have my

Reviewed-by: Derek Foreman <derekf at osg.samsung.com>

for the current approach - but I would like to give Pekka an opportunity 
to veto, since I think strictly speaking he's correct. :)

Thanks,
Derek

>> Otherwise, I like the way you've split up the series, and I've reviewed your
>> new patches.
> 
> Thanks a lot! I'll leave them sit for a couple more days to see if
> anyone spots anything and then just push them if not.
> 
> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 



More information about the wayland-devel mailing list