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

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Adrian Perez from comment #3)
> (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.
> 

Not exactly.
The current code triggers the event if it gets the notification that there is something to read. This happens:

1. UIProcess writes 1 to the eventfd
2. WebProcess receives the notification that there is something to read
3. NetWorkProcess receives the notification that there is something to read
4. WebProcess try to read the data on the eventfd (ok)
5. NetWorkProcess try to read the data on the eventfd (fail with EAGAIN, but thats ok in the current implementation)
6. WebProcess triggers the memory event
7. NetworkProcess triggers the memory event.


That is what happens when it works fine (the two process receive the event).

But it is racy, it all depends on the notification (on point 3) happening before the first read (on point 4). Otherwise there won't be notification for the other process. And when more than one webprocess is in use it becomes even more racy because there are more subprocess trying to get the notification in time.


> > 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.
> 

I think that with signalfd all the usual problems of using signals can be avoided easily, can't be?

Using multiple eventfd file descriptors complicates even more the implementation, which is already fairly complex.

> 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?

Not sure. This can be a good idea, indeed.

-- 
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/0a965d52/attachment-0002.html>