Yielding to finished task results in fatal exception

[omus]

Behaviour on Julia 1.5.3, 1.6.1, and 1.7.0-beta2:

julia> t = @async true
Task (done) @0x00007fba6f5fb730

julia> yield(t)
ERROR: fatal: error thrown and no exception handler available.
TypeError(func=:typeassert, context="", expected=Int32, got=nothing)
jl_type_error_rt at /home/omus/julia/1.6/src/rtutils.c:119
jl_type_error at /home/omus/julia/1.6/src/rtutils.c:127
uv_write at ./stream.jl:992
unsafe_write at ./stream.jl:1064
write at ./strings/io.jl:185 [inlined]
print at ./strings/io.jl:187 [inlined]
#with_output_color#814 at ./util.jl:91
with_output_color##kw at ./util.jl:71 [inlined]
#printstyled#815 at ./util.jl:105 [inlined]
printstyled##kw at ./util.jl:105 [inlined]
display_error at ./client.jl:102
display_error at ./client.jl:107
jl_apply at /home/omus/julia/1.6/src/julia.h:1703 [inlined]
jl_f__call_latest at /home/omus/julia/1.6/src/builtins.c:714
#invokelatest#2 at ./essentials.jl:708 [inlined]
invokelatest at ./essentials.jl:706 [inlined]
_start at ./client.jl:487
jfptr__start_28164 at /home/omus/julia/1.6/usr/lib/julia/sys.so (unknown line)
jl_apply at /home/omus/julia/1.6/src/julia.h:1703 [inlined]
true_main at /home/omus/julia/1.6/src/jlapi.c:560
repl_entrypoint at /home/omus/julia/1.6/src/jlapi.c:702
main at julia-1.6 (unknown line)
__libc_start_main at /usr/lib/libc.so.6 (unknown line)
_start at julia-1.6 (unknown line)

The behaviour on Julia 1.4.2 didn't result in this fatal exception:

julia> t = @async true
Task (done) @0x00007fbaaa8109d0

julia> yield(t)

WARNING: Workqueue inconsistency detected: popfirst!(Workqueue).state != :runnable

[JeffBezanson]

This is documented as schedule(t, arg); yield(), which would throw an error since you can't schedule a finished task. Is an exception ok, or would you rather have it do nothing?

[omus]

An exception seems reasonable but the current behaviour where Julia abends does not.

[vtjnash]

You can schedule a finished task since we don't necessarily know that it will be finished, even though that has always been a violation of the scheduler ownership (hence the printed WARNING that something very bad happened). You cannot yield to it, but since the task yielding to it here is not the same as the task that scheduled it, it just gets worse. We probably need to do something similar to the past behavior where we detect the program state corruption and print the serious WARNING. The main question is going to be where this user bug can be reliably detected, particularly in the presence of threads.

[JeffBezanson]

In general it's just the same as any other data race, where multiple threads can fight over who schedules a certain task. So there's only so much we can do. We should just check the obvious error conditions like yielding to a task that's already in the done state, etc.

[lbilli]

Looks like a dup of #36866.