LGFae / swww

A Solution to your Wayland Wallpaper Woes
GNU General Public License v3.0
2.38k stars 70 forks source link

Finalize IPC behaviour #335

Closed rkuklik closed 3 months ago

rkuklik commented 4 months ago

This is probably largest part of my IPC journey. Currently very much work in progress. It will probably consist of three parts:

  1. Sketch out new types and API in general and implement alongside old system.
  2. Fuzz the hell out of it. Memory allocation and type safety very much depend on correctness of Serialize impl and is crucial to get right.
  3. If two previous steps work, out with the old, in with the new.
  4. Profit

Given that this will basically a rewrite of all communication, I would like opinion of other people before merging, as this is quite broad.

rkuklik commented 4 months ago

I may take me a bit longer than usual because I nearing the end of my final semester as an undergrad, so I apologize for that.

Of course, take your time. On that note, next two weeks I will also be less available, so no pressure. Also, good luck, hope you do well.

rkuklik commented 4 months ago

Hello, sorry for the delay. Given that my previous PR broke swww, I would close this PR and reopen it after I fix the breakage.

I have looked into postcard and must say, +1 for me. I consider dependencies one of the biggest wins with Rust, and would like to introduce serde and postcard to common crate. serde is goto solution for the ecosystem as a whole and postcard seems decent to me.

What do you think?

LGFae commented 3 months ago

Hey there. I am going to slowly get back into this over the course of the following weeks.

I've thought a lot about using serde and dependencies in general after your and @itsjunetime's comments. There's really just two problems I have with dependencies:

  1. they increase compilation time -- this isn't super troublesome, because most users will only pay the price for this once. It does make development more annoying, but not by much since we can use debug builds.
  2. they increase resource consumption in the daemon. This is the big one. Because the daemon will run "forever", I would really like for it to be as efficient as reasonably possible. For example, right now, after setting a static image, we unmap the underlying memory, such that RSS reports that just around 2.5MB are being used. I would really like to keep this behavior, and it's not going to be possible with higher-level libraries.

So, in conclusion, if you think using serde and postcard is possible while retaining the ability to unmap the underlying image bytes' memory, let's go for it.

rkuklik commented 3 months ago

Hello. I will close this and get back to it when I fix the regression with socket. As to the two points:

  1. they increase compilation time -- this isn't super troublesome, because most users will only pay the price for this once. It does make development more annoying, but not by much since we can use debug builds.

About speed of compilation, that depends. Cargo can concurrently compile multiple crates, so the biggest slowdown is in downloading them (with the now resolver, shouldn't be a big deal). When recompiling, you only recompile your crates, not the whole dependency graph, so it shouldn't impact development (can speed it up even), with the exception of link-time optimization (which can be turned off) and macro expansion (which shouldn't be an issue, only ones we want to be using are for serde).

  1. they increase resource consumption in the daemon. This is the big one. Because the daemon will run "forever", I would really like for it to be as efficient as reasonably possible. For example, right now, after setting a static image, we unmap the underlying memory, such that RSS reports that just around 2.5MB are being used. I would really like to keep this behavior, and it's not going to be possible with higher-level libraries.

I am not sure, why should they increase resource usage? You can stumble upon a poorly written crate, sure, but I would say using widely used and well maintained library can improve correctness and efficiency of your code. Big selling point of Rust is the ability to use high level abstractions without the penalties usually associated with them (Iterator would be a great example).

I think it is stupid to use crates like console_error_panic_hook which is about 20 lines of trivial code, but for complex tasks it is beneficial to lean into other people's work.

So, in conclusion, if you think using serde and postcard is possible while retaining the ability to unmap the underlying image bytes' memory, let's go for it.

Sure. I will fix the regression and get to it. Thank you and @itsjunetime for your work.