[Webkit-unassigned] [Bug 184261] [GTK][WPE] Memory pressure monitor doesn't reliable notify all the subprocesses

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 4 04:44:12 PDT 2018


https://bugs.webkit.org/show_bug.cgi?id=184261

--- Comment #3 from Adrian Perez <aperez at igalia.com> ---
(In reply to Carlos Alberto Lopez Perez from comment #2)
> I think this problem is unavoidable with the current implementation (with
> eventfd). My understanding is that when one of the subprocess reads the
> value of the eventfd, it destroys (consumes) it.

That's correct.

> But since the code does't read the value of the eventfd immediately after
> receiving the notification that there is something to read on the
> descriptor, there is a chance that more than one subprocess gets the
> notification. But its not something that happens reliably.

Ouch. That means that the process which gets scheduled first after
sending data to the eventfd is the one getting notified, and all the
others will miss the event.

> Perhaps an idea is using a signalfd descriptor instead, and sending a
> determined signal to all subprocess ?
> https://gabrbedd.wordpress.com/2013/07/29/handling-signals-with-signalfd/

Or, better than signals (which are always a bit clunky): the UI process
creates one eventfd which gets passed to each of the spawned processes,
and writes the event to _all_ of them (it's a broadcast). This would have
the downside of having one more additional file descriptor open for each
WebProcess, but would work.

There may be other options building upon cross-process IPC facilities but
in my head they sound like wouldn't be particularly nicer to integrate than
having an eventfd per process (semaphones, anyone? :D)


BTW, is there any reason why WebKit IPC cannot be used in this case?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180404/ef2e1229/attachment-0002.html>


More information about the webkit-unassigned mailing list