3 ms·
Why even give out (a reference to, ownership of) an object that represents an output, when the output might disappear at any time? You could instead have some o
by _-___________-_ 6y ago
Why even give out (a reference to, ownership of) an object that represents an output, when the output might disappear at any time? You could instead have some output controller which encapsulates all the operations one can do with outputs, which can simply return Err(OutputNotFound) if you try to operate on an output that was disconnected between you learning that the output existed and you trying to do some operation on it.
- cycloptic 6y agoThis is covered in the article: >This naive style implementation could work, however it would cause a lot of branching code. Each call to wlroots will require a check to see if the handle has been dropped, even though it almost certainly has not been dropped (it can only be dropped between event callbacks, wlroots/Wayland is callback based). This means there will be unnecessary paths (that are hopefully marked cold) that either panic or return an error.
- baseballdork 6y agoWould this not be necessary in C? I've not written C since that one semester in college, so I'm having a hard time imagining how C handle this differently.
- cycloptic 6y agoIt depends. Copying my response from farther down in the thread: >In C, you're supposed to listen for a "destroy" event on the output and then in the handler you would delete all your references to the object. If this wasn't satisfactory for whatever reason, then you could implement it as a weak pointer and check for null every time, but you wouldn't have to.
- _-___________-_ 6y agoI'm going to go out on a limb and assume that they did not build a small proof-of-concept and do some benchmarking to see if those unnecessary branches actually result in any meaningful performance issue in the context of a Wayland compositor.