Thread safety

[ids1024]

libxkbcommon can be awkward to use in a multi-threaded context given the use of reference counting in a non-thread-safe way. In particular it's proven inconvenient with how Smithay (a Rust library for building compositors) wants to use types like xkb_keymap.

Would there be any interest in making libxkbcommon APIs thread safe? Making reference counting thread-safe should be relatively simple with atomic operations. That would be enough to make xkb_keymap thread safe since it is immutable... except it contains a reference to xkb_context, which is reference counted and mutable. That is a bit more complicated to deal with.

(I'm also not sure if libxkbcommon can be used in systems where atomics and mutexes wouldn't be available, or how that would best be addressed.)

[bluetech]

In particular it's proven inconvenient with how Smithay (a Rust library for building compositors) wants to use types like xkb_keymap

Can you expand on this a bit? I mean, why does Smithay need to share (send?) xkb_keymap between threads.

Overall not opposed to making xkb_keymap thread safe if it makes sense and is not too hard (I think all we need is atomics, we can use stdatomic.h for it, but it's not supported everywhere so would need some polyfills). But I'm curious to hear the use case.

[ids1024]

Generally it can be awkward in Rust to deal with types that don't implement Send (i.e. they can't be safely moved between threads). Normally this trait applies, even for types that can't be used in multiple threads at once, but becomes a problem with reference counting like this.

smithay and smithay-client-toolkit have an unsafe impl Send for the types they use wrapping an xdg_state, I think mainly so they can provide a convention API without !Send types, but this means the Keymap can't be safely exposed in the public API in any way. Which has proven awkward for something I'm trying to do with these libraries (Smithay/smithay#750, Smithay/client-toolkit#299), though there may be a better way to deal with that.

It shouldn't be too hard to just create an independent xkb_keymap by converting it to a string and back, anyway. But it would be nice if xkb_keymap were thread-safe. Things like the log_fn in an xkb_context might complicate that; if the issue was just the refcounting in xkb_keymap this would be quite simple if support for atomics can be assumed.

Edit: So this probably isn't essential for anything in Smithay, but it may be convenient if it could be improved.