On 5/12/12 4:24 AM, james wrote:
Its not clear to me that the former is (or could be, given the memory model for shared data) on the cards, but I'm interested in the latter.
Rust does indeed have localized GC per task. It's one of the major design goals.
The docs suggest that a task's state can be polled - but that really sucks IMO. I couldn't find a way to subscribe to a 'death event' for a task - is there one?
There is. When you spawn the task, you must set the notify channel. The task will then fire a message to this channel when it finishes. You can set the notify channel by using `set_opts()` on the task builder.
Also, it would be handy to bind channels to tasks so that they automatically become invalidated if there is no longer a consumer.
This is precisely what happens. You can send to a channel tied to a dead port. The message just gets dropped on the floor.
Also for a port, it is not clear what happens if a task is blocked in comm::recv and the port should be closed or otherwise invalidated (I would hope to return in an error state) or if some timeout occurs and I want to wake up - I know it is possible to peek but that suggests a polling structure again if one doesn't want to get stuck with tasks in recv when you want to tear down some or all of the app.
I'm not quite sure what you mean here, actually. I know we are working on timers and so forth but I'm not sure why the task should be closed while it is blocked on the port. One scenario I can think of would be Erlang like kill-groups (which we don't currently have), but usually in our system at least tasks kill themselves, so if they are blocked they don't need to die.
In general, our task model is pretty close to Erlang, but task death is one of those places where we differ. I am not sure if that's a good thing or not. The Erlang model strikes me as a bit odd—it seems like most apps use a directed, hierarchical graph built on a set abstraction, and that seems backward—but I am nowhere near experienced enough with Erlang to say that with any confidence.
Niko _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
