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.
OK, that's nice. Is this in the docs?
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.
OK but in Erlang its also possible to start monitoring after the fact.
I think that is useful when doing internal pub/sub or callback
architectures - you can tell whether your clients are dead.
It may just mean that I have to have a central service that tracks
everything else and broadcasts, but it seems to me that this is handy in
the runtime.
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.
Well, that's not what I meant, in that I might want to get an error
indication, for the same reason as above.
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.
If I have tasks waiting for messages from a dispatcher and the
dispatcher dies (and perhaps if the whole app is closing down) then its
handy to have at very least some whay to indicate that the app is
shutting down globally, and for everything to check this periodically if
it is otherwise idle. Erlang's wait with timeout (and indeed the
timeout waits for locks and condition variables normal in shared data
synchronisation models) make this handy. I mistrust 'wait for ever'
models - its easy to lose track of something and have trouble recovering.
Yhanks
James
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
