Multithreading on xlibre

[clhin]

Describe the feature

Implement X11 multithreading to allow for multiple threads to conduct operations.

It should be implemented because

Large processes can hang the system if not taken care of properly, Artem Tashkinov writes how this causes problems, saying "Certain applications running intensive graphical operations can easily freeze your desktop (a simple easily reproducible example: run Adobe Photoshop 7.0 under Wine, open a big enough image and apply a sophisticated filter - see your graphical session die completely until Photoshop finishes its operation)." A modern display system should probably have at least one thread for input and one for drawing objects on screen.

What are the alternatives?

You could either do fork + exec, which would explode resource use of x11, or you could do nothing and continue asking the user to deal with it.

Additional context

I do not know enough about the x11 codebase to make statements about implementation, so I will have to study it more, but I do think that if namespaces are encapsulating the clients, we could default to making all programs have their own namespace to allow for better resource control so less locking is needed.

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[metux]

Artem Tashkinov writes how this causes problems, saying "Certain applications running intensive graphical operations can easily freeze your desktop (a simple easily reproducible example: run Adobe Photoshop 7.0 under Wine, open a big enough image and apply a sophisticated filter - see your graphical session die completely until Photoshop finishes its operation)."

Those hangs are probably due desktop environment lockups, not the Xserver itself.

But indeed, multi-threading is planned for the future. There's still a lot of preparational work to do before, and that would likely break the driver ABI.

[clhin]

But indeed, multi-threading is planned for the future. There's still a lot of preparational work to do before, and that would likely break the driver ABI.

Care to elaborate for those of us interested in contributing to this?

[ArmanHayots]

Hope also to see SIMD in action someday.

[iacore]

Please use actor-style concurrency instead of POSIX threads.

[metux]

But indeed, multi-threading is planned for the future. There's still a lot of preparational work to do before, and that would likely break the driver ABI.

Care to elaborate for those of us interested in contributing to this?

okay, that's a pretty big story ...

• first thing I'm planning to do is giving each client a separate IO thread: split whole read()/select() logic into one thread per client. the actual request dispatching still needs to be serialized by a global dispatch lock (so only one client's request can be actually handled at a time). before we can do this, we a) have to make sure nobody's writing into another client's input buffer, output need to be turned into packet queues (list of x_rpcbuf_t) and threadsafe.
• sending messages (ie putting them into client's out queue) must be made threadsafe
• investigate request handlers one by one whether they can be made threadsafe (->make all data structures touched by them threadsafe) and those who're really ready can release the global dispatch lock early.
• at least those functions not calling into drivers then can run in parallel to the others
• drivers are a bit more complicated ...