7 ms·

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

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 in Rust, I think it would make for a robust window system. I also know that starting from the position of "this will be written in Rust" would force the issue of memory ownership to the fore and result in a different architecture from the start.

ajross 8y ago
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 where in C you can just do it anyway, Rust is likely to flip out over your wrapper object abstractions. [1] I mean sure, technically it is memory management, but you know what I mean.
- klodolph 8y ago
  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 wrap an OpenGL texture with a C++ class either decides to accept that RAII doesn't completely work here, or refactors it so that you manage something like handles to textures, which is a bit silly because you are really at that point managing handles to handles to textures.
  - ska 8y ago
    re: the handles to handles stuff ... I don't think that's so silly really, when you are talking about a resource that in some fundamental sense belongs to a different system (in this case OpenGL). Sure, that system gave you a handle, but if the semantics of managing that handle aren't 1:1 matched with your languages model of things, another level of indirection is a clean way to handle it.
    - anyfoo 8y ago
      And just think about what most file and I/O wrappers, that are part of the standard library in most higher level languages, e.g. file objects in python, streams in C++ etc., naturally do: They also just wrap (for example) POSIX file descriptors, which are handles, with their own handles, i.e. the file object/Stream/whatever.
      - ska 8y ago
        Right, it's the same basic problem, and a good pattern to solve it.
      - klodolph 8y ago
        Maybe I didn't explain what's happening in OpenGL properly, because that comparison doesn't work at all. With e.g. std::ofstream, you are wrapping a handle, such as a POSIX file descriptor. So that part of your description is accurate. However, this is different from what happens with OpenGL. The problem is that if you wrap an OpenGL texture (which is a handle), you end up with some problems because you can only free it with the correct context active, and it might become free for other reasons besides the wrapper being destroyed. So you are no longer wrapping a handle (like std::ofstream), but you are actually creating a new handle-to-handle, and wrapping that, and explicitly managing the lifetime OpenGL resources with a separate object somewhere else. Of course, you could just wrap an OpenGL texture, explicitly decide not to handle context invalidation, and then be careful to ensure that your objects get destroyed with the OpenGL context active. You lose some flexibility and you have to babysit RAII to be sure it "does the right thing". So what I'm saying here is that OpenGL textures are not like file handles.
- jandrewrogers 8y ago
  Yes, a similar issue exists in C++ too when managing some types of resources in database kernels. Some types of resource management are a poor fit for idiomatic ("safe") resource management in C++. In that language, you always have the option of custom, non-idiomatic resource management -- everything you might want to do is always possible in principle. You avoid it to the extent practical but there are a few times when this kind of resource management is unambiguously the correct software design and engineering choice. It is a bit like "goto". Rarely used for good reason but there are times when any other implementation will be decidedly much worse. I've hashed this out extensively when looking at implementing a database kernel in Rust (I’ve had Rust experts among my C++ programmers). Technically it is possible to implement these things in a safe way in both C++ and Rust. However, it comes at a cost of an unreasonably complex and inefficient software architecture in either language, so you would not want to actually do it that way in a sane code base.
- pcwalton 8y ago
  I have a very simple GPU abstraction in Pathfinder that has to manage lots of these objects, and it was easy and natural to get them to work. Sometimes I have to throw in a reference count here and there to make sure things are destroyed in the right order. If the model doesn't fit perfectly into Rust's ownership system, I usually just do the checks dynamically and panic, or accept logic bugs (but not memory safety bugs), if things go wrong. Is that admitting failure? Perhaps. But it's also just choosing my battles. I'm trying to keep my code clean and ship, not prove it correct. Memory safety problems are pernicious enough that it's worth significant effort to rule them out, but almost everything else is a judgment call.
- codedokode 8y ago
  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.

ajross 8y ago

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 where in C you can just do it anyway, Rust is likely to flip out over your wrapper object abstractions. [1] I mean sure, technically it is memory management, but you know what I mean.

klodolph 8y ago
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 wrap an OpenGL texture with a C++ class either decides to accept that RAII doesn't completely work here, or refactors it so that you manage something like handles to textures, which is a bit silly because you are really at that point managing handles to handles to textures.
- ska 8y ago
  re: the handles to handles stuff ... I don't think that's so silly really, when you are talking about a resource that in some fundamental sense belongs to a different system (in this case OpenGL). Sure, that system gave you a handle, but if the semantics of managing that handle aren't 1:1 matched with your languages model of things, another level of indirection is a clean way to handle it.
  - anyfoo 8y ago
    And just think about what most file and I/O wrappers, that are part of the standard library in most higher level languages, e.g. file objects in python, streams in C++ etc., naturally do: They also just wrap (for example) POSIX file descriptors, which are handles, with their own handles, i.e. the file object/Stream/whatever.
    - ska 8y ago
      Right, it's the same basic problem, and a good pattern to solve it.
    - klodolph 8y ago
      Maybe I didn't explain what's happening in OpenGL properly, because that comparison doesn't work at all. With e.g. std::ofstream, you are wrapping a handle, such as a POSIX file descriptor. So that part of your description is accurate. However, this is different from what happens with OpenGL. The problem is that if you wrap an OpenGL texture (which is a handle), you end up with some problems because you can only free it with the correct context active, and it might become free for other reasons besides the wrapper being destroyed. So you are no longer wrapping a handle (like std::ofstream), but you are actually creating a new handle-to-handle, and wrapping that, and explicitly managing the lifetime OpenGL resources with a separate object somewhere else. Of course, you could just wrap an OpenGL texture, explicitly decide not to handle context invalidation, and then be careful to ensure that your objects get destroyed with the OpenGL context active. You lose some flexibility and you have to babysit RAII to be sure it "does the right thing". So what I'm saying here is that OpenGL textures are not like file handles.
jandrewrogers 8y ago
Yes, a similar issue exists in C++ too when managing some types of resources in database kernels. Some types of resource management are a poor fit for idiomatic ("safe") resource management in C++. In that language, you always have the option of custom, non-idiomatic resource management -- everything you might want to do is always possible in principle. You avoid it to the extent practical but there are a few times when this kind of resource management is unambiguously the correct software design and engineering choice. It is a bit like "goto". Rarely used for good reason but there are times when any other implementation will be decidedly much worse. I've hashed this out extensively when looking at implementing a database kernel in Rust (I’ve had Rust experts among my C++ programmers). Technically it is possible to implement these things in a safe way in both C++ and Rust. However, it comes at a cost of an unreasonably complex and inefficient software architecture in either language, so you would not want to actually do it that way in a sane code base.
pcwalton 8y ago
I have a very simple GPU abstraction in Pathfinder that has to manage lots of these objects, and it was easy and natural to get them to work. Sometimes I have to throw in a reference count here and there to make sure things are destroyed in the right order. If the model doesn't fit perfectly into Rust's ownership system, I usually just do the checks dynamically and panic, or accept logic bugs (but not memory safety bugs), if things go wrong. Is that admitting failure? Perhaps. But it's also just choosing my battles. I'm trying to keep my code clean and ship, not prove it correct. Memory safety problems are pernicious enough that it's worth significant effort to rule them out, but almost everything else is a judgment call.
codedokode 8y ago
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.