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).
Well, the interesting case is not that something tests alive but dies
before I test again, but to indicate that something is definitely dead,
and whatever resources I have related to generating content are not
needed anymore.
Wait with timeout is currently called `std::timer::recv_timeout`.
Given that the blocking case is effectively 'wait with infinite timeout'
I think its very confusing to seperate the two.
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.
I'm interested however in my applications idea of when the application
should exit - rather than some system view of it. Perhaps I have a C++
dev's idea of this, but its handy to have some way to know that for
example 'all' threads will 'soon' return from blocking waits and will
check and then start to unwind, so that they can be joined in some sort
of ordered way.
It does seem uncontrolled for everything to be running and then closing
in a system chosen and arbitrarily ordered way is potentially scary,
especially if you have C libraries that you want to close down in an
ordered way if at all possible.
James
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
