- New York City
- https://pub.gajendra.net/
- Joined on
2025-10-08
So this gets into some of the weird semantics between POSIX locks and flock, but do you want to lock against threads in your own process, or other processes? Or both? The use of Atomics suggests that the former is at least on your radar.
Given that you do Not want to collide with an actual X server process (or ssh daemon simulating one), why not use these names as the lock file directly? It's not just that you have your own namespace to protect colliding with an already-running server, but also that a server started subsequently to you running could collide with you (though since it involves binding a socket, that is unlikely). But an O_EXCL create here would pretty much guarantee isolation between actual X servers and you.
Oh! You do the first. I got confused by searching for /tmp/.X{}-lock, but that's to try and avoid racing against another process starting an X server.
The big issue I'd worry about, I suppose,…
So...A couple of things you can do to make this a bit more robust.
I think the return statements here are redundant: the match is the only expression in this function.
Is there a good reason not to change the type signature on the C side to make this explicitly unsigned? A negative number there feels relativistically impossible?
I don't quite get this; it appears to not just check, but consume and drop, global idle handlers. Perhaps the name could be changed to reflect that? run_global_idle_handlers or something? The repeated with_global_handlers blocks are interesting; I believe that's intended for the case where an idle handler is added during processing?
Nit: a couple of do comments on this struct and callback would be nice.
I had thought at one point that it might be nice to try to make this generic over some type T, and bifurcate usage between c_void and usize, but looking at the sheer volume of places this code is used, I think that would be tedious and premature. It's a bummer that we have to do a lot of pointer casting as a result, but ... c'est la vie.
oh, hmm. No, not really, then. In that case, I'd recommend using the "provenance" based functions, though: .with_addr and so forth, if that's reasonable: https://doc.rust-lang.org/std/ptr/index.h…
This is certainly an improvement! I'm a bit surprised there aren't crates providing better bindings to both Xft and pango, but that's a separate matter.
Instead of the comments, why not give these proper names via let bindings?
Could you use .cast() here instead of as (and similarly elsewhere)?
The actions in the match here are repeated verbatim in all cases (I think). Perhaps delegate to a small helper function that implements just that logic?
It strikes me that if you used BTreeMap here instead of HashMap, you could make the constructor for NotificationCenter by pub const fn new() and do away with the OnceLock bits in with_global_default, instead using a static Mutex<NotificationCenter>.