[BuildStream] Proposal: Moving UI into a subprocess

[Phil Dawson <phil dawson codethink com>]

Hi All

In Daniel's latest batch of profile analysis [1]. He noted that UI 
rendering was consuming around 50% of the straight line cpu time of the 
parent `bst` process. As such, it may make sense to delegate the UI 
rendering to a subprocess to avoid blocking the scheduling of useful 
work while rendering UI events. Tom and I have been thinking about how 
best to approach this and have outlined our thoughts bellow.

Currently, most of work done for the UI rendering occurs in 
App._message_handler (via context.message_handler), this being the 
central point through which BuildStream's user facing messages pass. 
Moving the work done by this  message handler into a subprocess is thus 
the obvious way to get some performance gains.

The UI rendering requires access to the context, and to loaded plugins. 
This means that any UI subprocess should be spun off after load time.

One approach to this would be to have a context manager  on context, 
which would spawn a new process (which may be suited to a daemon 
process) running context.message_handler and replace 
context.message_handler with a queue feeding into this new process. The 
process would be created using spawn for compatibility with Windows.

While as far as I can see, any exceptions thrown in the UI subprocess 
would be due to bugs in BuildStream, we want to be able to communicate 
these exceptions up to the main process in order to show a nice BUG 
message on the fronted, this will have to be done by catching any 
exception in the subprocess and passing it back to the main process.

When exiting this context manager, the subprocess would be torn down and 
the UI rendering moved back into the main process. This context manager 
could then be used to wrap calls to Scheduler.run in _stream.py.

There are issues we are aware of and still need to figure out with this 
approach:

1) The interrupt handler and the global exception handler would remain 
in the main process. We'll need to ensure that when these are called 
that the UI subprocess does not attempt to output other messages at the 
same time.

2) We have not yet worked out how interactivity would work with this 
approach and would welcome suggestions here.

As a first step, we think it makes sense to implement this without 
interactivity, at which point we take some performance measurements to 
ensure that moving the UI into a subprocess is actually worthwhile.


Cheers,

Phil and Tom





[1] 
https://mail.gnome.org/archives/buildstream-list/2019-April/msg00024.html

--
Phil Dawson, Software Engineer                          Codethink Ltd
https://www.codethink.co.uk/
We respect your privacy. See https://www.codethink.co.uk/privacy.html