Hi, 2013/4/26 Patrick Walton <[email protected]> > > On 4/26/13 6:53 AM, Gábor Lehel wrote: >> >> Probably a crazy idea, but would it be possible to do something where if >> the parent task launches a child task, and then does nothing else except >> wait for the child to finish, it's not actually implemented by launching >> a new task, but instead by calling the closure in place? > > > The new scheduler is designed to allow *almost* this -- `spawn` will simply > grab a cached stack segment (assuming there's one available) and context > switch to the task immediately.
I have a closely related issue currently. To implement thread-safe method calls to GLib objects, I chose to add a slow (and lock-prone) path of making a blocking FFI call passing an owned closure to another thread, which runs the event processing loop where the call's data are presumed to be safely accessible. This is done as the last resort when invoking the call on stack is not possible. It is admittedly quite ugly [1]. Now, if I were certain that one task can always read and write data (in unsafe code) on another task's stack provided that the latter task is blocked, I could scrap half of that logic and data copying, and just pass a stack closure across the threads. I'm pretty sure it actually works now. But I need a word from On High that it should be a supported use case. [1] https://github.com/mzabaluev/grust/blob/879f51ff84168d5757bdb370afe108bd347a1552/fauxgen/gio.rc#L179 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
