On 4/7/13 7:49 AM, Mikhail Zabaluev wrote:
Hi,

I've started playing with Rust bindings to GObject:
https://github.com/mzabaluev/grust

The intent is to make any API that provides a GObject introspection
safely usable in Rust. There are two important things about GLib objects:
1. The objects are reference counted in a thread-safe way.
2. The objects in general are not thread-safe: threads calling methods
on one object need to be synchronized.

In my proof-of-concept code, the Rust safe wrappers for the objects are
intended to be cloneable and sendable by virtue of the GLib refcounting.
But this may mean that an object may end up being used concurrently from
multiple tasks. Are there any best practices for wrapping such objects?
One solution I see is to dispatch all GObject calls through a dedicated
ever-running task initialized on program startup (GObject needs an
explicit init call anyway, so it's no big deal to add), but this grand
central approach may not be optimal or flexible enough.

This is a use case for the `#[nonsendable]` or `#[nonowned]` annotation on structs. This annotation isn't implemented yet, but it's a common feature request, as it will be needed for non-thread-safe reference-counted smart pointers too. With that attribute you could ensure that GObject values can only live in one thread at a time.

Another topic of interest is casting. GObject provides runtime type
information and supports dynamic type checks. This means we can safely
down- and side-cast between traits representing GObject classes or
interfaces, but we need a custom cast implementation. Is there any
idiomatic trait to reuse?

There isn't anything in the standard library to do that, but the Rust Core Foundation bindings have a system similar to what you're proposing. (CF is a GObject-like system.) The trait definitions in `rust-core-foundation` are a little complex for my taste though--if you can come up with something simpler then I'm all for it.

Patrick

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to