On 10-09-22 02:20 PM, Peter Hull wrote:
Some of the programs under 'test' give a compiler warning
warning: "spawn" with unused result spawns a task that immediately dies
Does that literally mean what it sounds like it does - surely those
programs won't run properly if so? I've edited all the affected files
to assign all those results to auto variables, and set up a pull
request if you want.
I believe the behavior of many of those tests is either (a) intentional,
in order to test sudden-death scenarios or (b) subject to future changes
anyways, as work proceeds on the runtime task-scheduling system.
Michael Bebenita was working with them over the summer and I'm not
certain what the state is. Perhaps he can chime in.
I'm also not certain whether we're going to maintain the notion of a
task's lifetime being coupled to the lifetime of the variable(s)
referring to it; we may instead cause all child tasks of a parent task
to live in an "invisible" table implicitly held in the parent, such that
the children are not killed until the parent explicitly requests it; in
that case "task" values would be weak references and the warning would
be obsolete. Several people have expressed surprise already that task
lifetime is coupled to the owning variable; perhaps this is sufficiently
unlike (say) the unix process model that we should
IOW, I am neither sure of the need for that warning, nor the need to
correct cases flagged by it (nor, incidentally, the mechanism used to
enforce it). Input on any of these issues would be welcome.
Supplementary question - some files (e.g. task-comm-1.rs) have code
like "spawn thread func()". What's meaning of the word "thread" in
this context?
It specifies a different sort of domain into which the task should be
spawned. In this case, a thread domain. This means that the spawned task
becomes the root task of a new, independent OS-level thread. I believe
the parser also accepts the word 'process' as a domain specifier, but
neither the rest of the compiler nor the runtime supports spawning into
a separate OS-level process yet. Our intention is to support this
eventually.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
