3 ms·

It's a theoretical problem. The window-management parts of sway are tiny and having them in the same process means you don't have to do IPC every time your wind

It's a theoretical problem. The window-management parts of sway are tiny and having them in the same process means you don't have to do IPC every time your windows do something. That simplicity means it's easier to write code that doesn't crash. Most of the heavy-lifting is done in wlroots anyway. wlroots based compositors really do implement just their own flavour of compositing what you see on the screen on top. That said, you still can use IPC, if you really want to; I have an external window manager that augments Sway's tiling system via its i3-compatible IPC mechanism to arrange my windows in a way that Sway doesn't do natively. If you really wanted to, there's nothing stopping you from writing a wayland compositor that uses an external window manager. At any rate, I don't buy the reliability argument at all. I've used sway since 0.10 or something, and I only ever remember crashing it once, and I fixed that bug myself. :P

jude- 6y ago
I'd say it's a very practical problem. Why put N different things that used to run in separate protection domains into the same protection domain? Have we gotten N times better at writing code that doesn't crash? Do we believe that we can put N different things into the same address space but somehow ensure that a security hole in one of them won't compromise all of them? Have computers gotten so slow in the last 30 years that doing IPC is no longer an option? I'm glad that you have personally not encountered a crash in Sway -- I really, truly am. But let's not pretend that a data point of 1 indicates a trend.
- cycloptic 6y ago
  In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.
  - jude- 6y ago
    > In practice, placing everything in one process seems to reduce the total attack surface. Surely you're joking. Privilege separation [1] is a thing for a reason. If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s [1] https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation
    - cycloptic 6y ago
      There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.
      - jude- 6y ago
        In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to? Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here. I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?

jude- 6y ago

I'd say it's a very practical problem. Why put N different things that used to run in separate protection domains into the same protection domain? Have we gotten N times better at writing code that doesn't crash? Do we believe that we can put N different things into the same address space but somehow ensure that a security hole in one of them won't compromise all of them? Have computers gotten so slow in the last 30 years that doing IPC is no longer an option? I'm glad that you have personally not encountered a crash in Sway -- I really, truly am. But let's not pretend that a data point of 1 indicates a trend.

cycloptic 6y ago
In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.
- jude- 6y ago
  > In practice, placing everything in one process seems to reduce the total attack surface. Surely you're joking. Privilege separation [1] is a thing for a reason. If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s [1] https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation
  - cycloptic 6y ago
    There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.
    - jude- 6y ago
      In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to? Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here. I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?