[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