Hi Jack, 2013/4/8 Jack Moffitt <[email protected]>
> > 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 what tends to happen in Erlang, although in some cases > multiple tasks would be available for dispatch (think SQL database > connections where each task owns a single connection). It would > probably work fine, and if it became a bottleneck you could have a > task per object perhaps, or wherever the thread-safe boundary lies. > Right; I don't think there is a general guarantee that any two GObjects can be concurrently used, as they may share data by implementation. So either it should be the grand central task, or maybe there is a way to weave a task context into every object wrapper. The latter looks difficult in the general case, as GObject does not maintain a concept of thread affinity or event loop affinity for the objects, the way Qt does. Best regards, Mikhail
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
