For a long time, utility processes were fairly simple and just did all their work on the main thread. Now we have cases where its got background threads to keep the main thread responsive. e.g. r493862. If I read r493862 correctly, it's using the main thread for IPC, and background threads to do potentially long running work.
Should we standarize threading in utility processes to mirror the browser process? By standarizing the threading model, those who work on utility processes don't have to worry about how any particular utility process has its threads structured. Following the browser process model means it is easy for developers to pick up.
i.e. Create an IO thread for IPC, and leave the main thread for doing work, with background threads also available if needed. Depending on what is loaded in the utility process, the code may be picky about what thread it runs on.
e.g. Some existing Windows printing code runs in a utility process and interacts with GDI.
e.g. We are currently prototyping moving printer drivers out of the browser process.
Comment 1 by benhenry@google.com
, Jan 10