On Mon, Apr 8, 2013 at 4:06 AM, Patrick Walton <pwal...@mozilla.com> wrote:
> 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.

Here's the issue request for #[non_owned] by the way:
https://github.com/mozilla/rust/issues/5601
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to