Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Giving up on wlroots-rs

way-cooler.org

Post reply on HN
Print view View original

21–30 of 126 posts

Re: Giving up on wlroots-rs

#21

Post by timidger »

Diggsey wrote: post #13

I can't speak to every issue which the author might have encountered, but there is a better solution to the lifetime management problem than the two mentioned in the article. Instead of this: fn some_wlroots_callback(output_handle: OutputHandle, surface_handle: SurfaceHandle) { output_handle.run(|output| { surface_handle.run(|surface| { // maybe some more nested layers... }).unwrap() }).unwrap() } One can do this: fn…

Author here.

The problem with that design (which is a great design given what I presented in the article by the way!) is that it doesn't allow you to share handles across callbacks, which is mandatory to do anything interesting. I'm assuming here that you can't use the handles except for that callback context. If you can, then that presents a different problem.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

If you can own a context, even with a lifetime parameter it's possible to leak it using the Box api. That allows you to have access to a &'static CallbackContext. This will break that assumption that it only lives as long as the callback itself.

Re: Giving up on wlroots-rs

#22

Post by gpm »

ddevault wrote: post #18
gpm wrote: post #14

Earlier quoted context omitted.

Speaking as someone who dabbled in Wayland in Rust before (but a few years ago so my knowledge might be outdated), has not tried wl-roots, and uses Rust a lot (a) Only when talking about interacting with C libraries written in a certain style. So not in general, and not with most C libraries, but yes for implementing wayland compositors. (b) Don't know (c) Absolutely a negative reflection , there are two ugly things…

>(c) Absolutely a negative reflection, there are two ugly things going on here. The official wayland libraries use a ownership style that really only makes sense in C imho, and despite the claim that wayland is just a protocol you can't actually not use the official libraries, because the drivers only work with the official libraries. Not really sure what you're talking about here. Wayland is just a protocol, and a p…

At a glance, smithay depends on wayland-server depends on the official wayland libraries. More specifically the issue that makes this necessary is that it's the only way to get an OpenGL context (AIUI - it's been quite awhile since I worked on this).

Rust is special in that's it's even worse at representing it, but the C controlled event-loop/fd-based-dispatching/ownership model wayland uses isn't idiomatic in any language other than C. Maybe wlroots makes this better, like I said I've never used it and can't speak to it.

Re: Giving up on wlroots-rs

#23

Post by quietbritishjim »

scatters wrote: post #12
quietbritishjim wrote: post #6

I know very little about Rust or Wayland (I suppose I'm not the target audience) but I got lost very quickly here: > A Wayland “output” is the resource that represents a display device. Commonly this means it handles a computer monitor. This resource could disappear at any time in the life cycle of the application. This is easy enough to imagine: all it takes is a yank of the display’s power cord and the monitor goes…

I think you missed this part: > [the resource handle] can only be dropped between event callbacks, wlroots/Wayland is callback based So "at any time" means between any two user callbacks, but not during them. Error states really aren't a solution IMO, as they tend to pollute the entire interface in that methods that would be expected to work unconditionally can now fail or panic. Either you have to check each method…

> > [the resource handle] can only be dropped between event callbacks, wlroots/Wayland is callback based

Thanks, that certainly makes a hell of a lot more sense.

Re: Giving up on wlroots-rs

#24

Post by timidger »

mcguire wrote: post #15

" A Wayland “output” is the resource that represents a display device. Commonly this means it handles a computer monitor. This resource could disappear at any time in the life cycle of the application. This is easy enough to imagine: all it takes is a yank of the display’s power cord and the monitor goes away. [Except it can't; it can only disappear between callbacks?] This is basically the exact opposite of the Rust…

Author here.

This output is attached to a callback parameter, but you can takes this resource from the callback in C (because it's just a pointer you copy around) and use it in other callbacks. Eventually a "special" callback that will trigger to indicate that the data the pointer refer to will be cleaned up and you need to remove all of your references to that resource because otherwise they will be dangling.

Re: Giving up on wlroots-rs

#25

Post by Sir_Cmpwn »

gpm wrote: post #22
ddevault wrote: post #18

Earlier quoted context omitted.

>(c) Absolutely a negative reflection, there are two ugly things going on here. The official wayland libraries use a ownership style that really only makes sense in C imho, and despite the claim that wayland is just a protocol you can't actually not use the official libraries, because the drivers only work with the official libraries. Not really sure what you're talking about here. Wayland is just a protocol, and a p…

At a glance, smithay depends on wayland-server depends on the official wayland libraries. More specifically the issue that makes this necessary is that it's the only way to get an OpenGL context (AIUI - it's been quite awhile since I worked on this). Rust is special in that's it's even worse at representing it, but the C controlled event-loop/fd-based-dispatching/ownership model wayland uses isn't idiomatic in any la…

Smithay has both a pure Rust and libwayland-based implementation, you can pick iiuc.

And the OpenGL problem isn't fair, OpenGL is such a flaming heap of poor design that binding to libwayland to use it is the least of your problems. Better to use Vulkan instead for this purpose imo.

Event loops are common in many languages.

Re: Giving up on wlroots-rs

#26

Post by vectorEQ »

good ol C :). Thanks for sharing these experiences. Happy to see some example of the places where rust still falls a little short / is a bit too restrictive for system programming. a lot of people deny this, but there's plenty of situations where you just want plain old C for it's straightforwardness to implement your own design. if you want to do it the 'rust' way, you find yourself restricted in all kinds of ways. if you can live with those restrictions it's great, but sometimes you just get stuck. Good luck on the rebuild in C!

Re: Giving up on wlroots-rs

#27

Post by ghettoimp »

herodotus wrote: post #8

> Way Cooler is a Wayland compositor that was written in Rust using wlc I know it is not easy, but I wish the author could have started with a paragraph that could help someone like me know whether or not the rest of the article would be something I would like to read. How about something like this (and of course I may some of the facts wrong, but I want to be as constructive as I can): "Wayland is a Windows manager…

Definitely. So often, whole articles and even much of the ensuing discussion will be using project names and acronyms that I don't know about. A sentence or two of context, or even just links going off to the project/acronym the first time it is used, are wonderfully useful for the wider audience.

Re: Giving up on wlroots-rs

#28

Post by 4bpp »

How does Rust handle these problems in the context of file I/O? I'm sure there is an axiomatically idiomatic (official) implementation of it as part of the language distribution, and at the same time file handles seem conceptually very similar to display handles and should have similar failure patterns (space can run out, a disk can fail, a plug-and-play disk can be yanked out at any time...).

Re: Giving up on wlroots-rs

#29

Post by gpm »

Sir_Cmpwn wrote: post #25
gpm wrote: post #22

Earlier quoted context omitted.

At a glance, smithay depends on wayland-server depends on the official wayland libraries. More specifically the issue that makes this necessary is that it's the only way to get an OpenGL context (AIUI - it's been quite awhile since I worked on this). Rust is special in that's it's even worse at representing it, but the C controlled event-loop/fd-based-dispatching/ownership model wayland uses isn't idiomatic in any la…

Smithay has both a pure Rust and libwayland-based implementation, you can pick iiuc. And the OpenGL problem isn't fair, OpenGL is such a flaming heap of poor design that binding to libwayland to use it is the least of your problems. Better to use Vulkan instead for this purpose imo. Event loops are common in many languages.

> Event loops are common in many languages.

Including rust - I'd have to dig in again to remember exactly why the wayland one was so bad at interacting with rust to be honest. I know it had something to do with how ownership of callbacks and objects interacted with the event loop. I know I didn't think I could represent it much better in python.

OpenGL may be a shit show, but it's necessary (to be able to expose it to clients) for a modern desktop. I think I was doing this either before or in the really early days of Vulkan so I don't really know how that changed things.

Re: Giving up on wlroots-rs

#30

Post by timidger »

steveklabnik wrote: post #7
blattimwind wrote: post #5

Earlier quoted context omitted.

> Does this end up being primarily a negative reflection on the general structure of A core problem in this case is wlroots using a memory management paradigm that isn't easily modeled in Rust. This isn't unexpected per se, since C leaves MM entirely to the developer, while Rust is opinionated.

I would say it's a bit more subtle than that. Rust can express this, but not safely. This is what the end bit is about. The question then becomes, is it worth it if it's largely unsafe? That's a complex question. Unsafe Rust still does give you a lot of advantages, namely that the checked constructs are still safe, even in an unsafe block. Unsafe Rust is slightly more annoying to write than safe Rust, and so that's a…

Author here.

Ignoring the social impetus in the Rust community to not use unsafe, I also don't feel like unsafe Rust is something I want to program in all the time.

When I program in safe Rust I can be happy once it compiles because I can ignore all of the safety problems that come from C and C++.

However in unsafe Rust not only is it much more difficult to express what I want syntatically (the lack of auto deref is very annoying, having to write (*base).value all the time gets very old) and semantically (there is no standard for the unsafe parts of the language - not so much a problem if only smallish parts of this usage is used (because once a standard comes out just that can be updated) but a problem if a whole program is written in it).

Unsafe Rust is "good enough" to try to encode these abstractions but I would not use it over C or C++.

Post reply on HN