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

111–120 of 126 posts

Re: Giving up on wlroots-rs

#111

Post by anyfoo »

klodolph wrote: post #109
ska wrote: post #106

Earlier quoted context omitted.

They don't behave like file handles - but at a certain distance if you squint at it looks like the same problem. The real issue isn't that OpenGL textures don't behave like file handles, but that neither of them behave quite like objects in your language, which can lead to problems. The specifics of how the behavior differs is I think less important that the fact that it differs. Of course, file handles are not the b…

> …but at a certain distance if you squint at it looks like the same problem… The whole discussion here is about how these things differ in subtle ways. The problem with “squinting” at the problem is you end up e.g. using RAII and then having to redesign your system because RAII doesn’t match, and the problems weren’t obvious when you started out. Not to make too fine a point about it here, but file handles are perfe…

Ok, file handles are often good matches, unless you start allowing for them being changed outside of the file object, e.g. being closed or their position pointer modified (by e.g. seeking or reading).

So my example might not have been the best, because usually, they have a closely matching lifecycle, but the greater point that I was trying to make is that managing handles of handles (of handles) is not weird if you have to do some impedance matching. Maybe file handles are often straightforward, and therefore only require one "additional layer of handle indirection", but there's probably other good examples like say, threads in thread pools, or a whole bunch of stuff that's going on inside an OS kernel, especially a multiprocessing one.

Re: Giving up on wlroots-rs

#112

Post by codedokode »

ajross wrote: post #19
ChuckMcM wrote: post #10

Earlier quoted context omitted.

I agree and was going to say the same. That there was a huge challenge in writing code to manage memory ownership, is not surprising because memory ownership is so fluid and adhoc in C and its derivatives. And when you are asked to make that ownership explicit, if the original designers hadn't been thinking about it, you get a lot of cases which they would not have considered. I would like to see a compositor written…

Not a wayland, wlroots or rust expert, but dollars to donuts says that it's not "memory" management[1] at issue, but resource allocation on the other side of the graphics driver. Vertex arrays, textures, framebuffers, shaders et. al. all need some kind of allocation strategy, can in the modern world often be shared between process contexts, and they really don't fit well into the metaphors of either C or Rust. But wh…

Wayland uses "objects" that can appear and disappear and graphic driver is unrelated here. For example, wayland has a "registry" and it sends notifications to clients when new objects appear there or disappear from it. I assume this unpredictability could become the problem for the author.

Re: Giving up on wlroots-rs

#113

Post by codedokode »

jandrese wrote: post #17
lucideer wrote: post #4

Question (for any more knowledgable readers here) from someone with a somewhat shallow understanding of the topics discussed: Does this end up being primarily a negative reflection on the general structure of: (a) Rust (b) wl-roots (c) Wayland (d) all three (e) none of the above, it's merely the incidental reality of trying to write code that's compatible/usable across multiple language ecosystems and none of the 3 p…

I read it as friction between how Rust sees its application model and the real world. Total ownership of a resource can't be maintained if some jackass goes and pulls the physical hardware out from under you. So now the Rust implementation gets crufted up with a zillion checks for unexpected changes to the underlying system that are clunky in Rust because that's supposed to be an exotic condition, not something you'r…

This can also indicate a problem in architecture: if the monitor can go away any time, you shouldn't store long time references to it and instead, for example, call a function to get current default monitor every time you want to do something. Or at least validate those references before usage.

Re: Giving up on wlroots-rs

#114

Post by uryga »

kccqzy wrote: post #75
pjmlp wrote: post #64

Earlier quoted context omitted.

JavaScript and Haskell get to enjoy the productivity of using a tracing GC though.

This doesn't really have much to do with the runtime. Certainly with a GC, programming would be easier, but I'm really talking about abstractions within the language. Rust already has language-integrated support for the Result monad. Rust doesn't have a general `do` syntax, but it has `?` which has made programming with the Result monad much easier. Can we think about the continuation monad and arrive at a new syntax…

i don't really know Rust apart from some curious onlooking, but afaik expressing monads (i.e. the Monad typeclass) in Rust is tricky – something to do with the lifetimes of closures and the objects they close over, i think. ([Idiomatic Monads in Rust] probably touches on that). it might be possible to just build it into the language a la Result or async/await though.

[Idiomatic Monads in Rust] https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in...

Re: Giving up on wlroots-rs

#115

Post by sly010 »

klodolph wrote: post #31
ajross wrote: post #19

Earlier quoted context omitted.

Not a wayland, wlroots or rust expert, but dollars to donuts says that it's not "memory" management[1] at issue, but resource allocation on the other side of the graphics driver. Vertex arrays, textures, framebuffers, shaders et. al. all need some kind of allocation strategy, can in the modern world often be shared between process contexts, and they really don't fit well into the metaphors of either C or Rust. But wh…

This is also something that causes some pain when using C++ with RAII. Logically it makes some amount of sense that you have e.g. a C++ wrapper for a texture in OpenGL, and it knows to call glDeleteTextures in its destructor. HOWEVER, the destructor can now only be called if the OpenGL context is active, and the texture may be deleted if the context is lost (which can happen). At some point anybody who's tried to wra…

The problematic pattern I see here is whenever you manage remote state, your local guarantees about how that state changes just don't work.

You would love to have the abstraction of a standalone texture and be able to pass it around as a value and change it's ownership, but you never really owned it. The only thing you ever owned is the context (or the connection in the case of the wayland protocol). The texture you borrowed. Freeing your texture is equivalent to returning it to the context you borrowed it from. Of course not having an explicit context in the OpenGL API makes this much harder :)

Re: Giving up on wlroots-rs

#116

Post by ska »

klodolph wrote: post #109
ska wrote: post #106

Earlier quoted context omitted.

They don't behave like file handles - but at a certain distance if you squint at it looks like the same problem. The real issue isn't that OpenGL textures don't behave like file handles, but that neither of them behave quite like objects in your language, which can lead to problems. The specifics of how the behavior differs is I think less important that the fact that it differs. Of course, file handles are not the b…

> …but at a certain distance if you squint at it looks like the same problem… The whole discussion here is about how these things differ in subtle ways. The problem with “squinting” at the problem is you end up e.g. using RAII and then having to redesign your system because RAII doesn’t match, and the problems weren’t obvious when you started out. Not to make too fine a point about it here, but file handles are perfe…

Yes, I am talking about this at a higher abstraction level than the specifics only of c++ & OpenGL textures. I guess that wasn't clear enough.

I was only attempting to make that point that wrapping handles with other handles, rather than being silly, is a pretty good pattern to address this problem, and it shows up all over.

The file handle thing I already pointed out; there are better examples.

Re: Giving up on wlroots-rs

#117

Post by ncmncm »

codesections wrote: post #69
fxfan wrote: post #63

Earlier quoted context omitted.

I'm surprised nobody mentioned this yet- a rust rewrite means you are more likely to invite contributions from a larger community.

> rust rewrite means you are more likely to invite contributions from a larger community I'd be really interested to know why you think that's the case. Somewhere around 3% of programmers know Rust, while over 20% know C. https://insights.stackoverflow.com/survey/2019#technology Naively, I would have thought that a C project would invite contributions from a much larger community. Sure (as I've personally experienced…

It is nice to think that 3% of programmers know Rust, but we all know that number is at least two orders of magnitude too large. It would be impossible to defend a claim that 3% of programmers know that Rust is a language.

Re: Giving up on wlroots-rs

#118

Post by shmerl »

Sir_Cmpwn wrote: post #67
pjmlp wrote: post #66

Earlier quoted context omitted.

C is the lingua franca of UNIX based platforms. Thankfully not all OSes bow to it.

>Thankfully not all OSes bow to it. Right, just the successful ones.

That's hardly an argument for using C though. Successful OSes today were started years ago when there was barely anything else to use. It takes a long time for OS to gain success. Rust is so young, that to evaluate success of an OS written in it, you'd need to wait comparatively. So time will tell.

Re: Giving up on wlroots-rs

#119

Post by pjmlp »

Sir_Cmpwn wrote: post #67
pjmlp wrote: post #66

Earlier quoted context omitted.

C is the lingua franca of UNIX based platforms. Thankfully not all OSes bow to it.

>Thankfully not all OSes bow to it. Right, just the successful ones.

We could say the same related to JavaScript and Web, and it doesn't make it better.

Don't mistake success due to quality and being widepread thanks to historical accidents, free access to source code and the consequence market forces of POSIX adoption.

Re: Giving up on wlroots-rs

#120

Post by pjmlp »

Sir_Cmpwn wrote: post #93
tomjakubowski wrote: post #91

Earlier quoted context omitted.

Not Windows.

Right, because Win32 is a shining beacon of good design. Thank god it's not C, right?

Meanwhwile Linux is still trying to catchup with the security level of mainframes.

68% of out of bound kernel expoloits in 2018, nice.

Post reply on HN