On 05/12/2012 12:52 PM, james wrote:
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.
I would be interested in the use cases for this. It would be easy expose
whether a port is still alive, but that doesn't help you to know whether
anybody will ever receive data sent to that port (maybe it dies
immediately after you check).
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.
Wait with timeout is currently called `std::timer::recv_timeout`.
The current behavior around runtime shutdown is that, when the runtime
decides it's time for the app to exit, it will kill all running tasks,
so every task blocking on a port will wake up and unwind on its own.
The task API is still evolving, especially around task killing and
linked failure, so contributions are very welcome.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
