On 04/26/2013 02:34 PM, Mikhail Zabaluev wrote:
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
_______________________________________________
Without looking too closely at the details, this sounds like a very
similar pattern to what the new scheduler does to return data through
context switches: 1) take a pointer to the local stack, 2) deschedule
the task, 3) fill the pointer in with a result, 4) reschedule task.
Barring whatever thread synchronization issues apply here, I think this
is an ok thing to do.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
