TaskHandler sometimes panics on kill

[Nukesor]

The TaskHandler seems to panic at some point when calling kill.

I obviously assumed that stuff would work just fine and added an unwrap or except at some branch of the code I thought to be safe.

Originally, at the time @gotbletu posted the comment, a panic in the TaskHandler wouldn't actually result in a panic of the program, since it wasn't in the main thread.
This again would result in the mutex being poisoned, since the thread died while the mutex was taken.

Commit de796c7 fixes this problem.
If this comes up again, pueued will properly shut down and crash as expected.
This can then be combined with a simple RUST_BACKTRACE-1 to get a better idea on what's actually wrong.

E.g.:

$ RUST_BACKTRACE=1 pueued -vv

Here's an excerpt of the original post:
Originally posted by @gotbletu in https://github.com/Nukesor/pueue/issue_comments/708027176

Steps To Reproduce

1. pueued -d && sleep 3 && pueue group --add fm && pueue group --add cl && pueue group --add dl && pueue group --add wb && pueue group --add vids && pueue group --add clips
2. pueue add --group vids 'mpv https://www.youtube.com/watch?v=jyCF9x1R_lw'
3. pueue add --group vids 'mpv https://www.youtube.com/watch?v=QCwqNWPaExQ'
4. pueue kill 1 && pueue remove 1
5. pueue kill 2 && pueue remove 2

$ pueue status

thread 'async-std/runtime' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', daemon/socket.rs:61:34
Error: Connection reset by peer (os error 104)

if i use sleep command then is working fine as normal

4. pueue kill 1 && sleep 1 && pueue remove 1
5. pueue kill 2 && sleep 1 && pueue remove 2

[Nukesor]

@gotbletu

I'm pretty confident, that I managed to fix this bug in fdf6346.

The cause for this problem was a preemtive status change of tasks on kill, which turned out to be unnecessary.
However, this status change (to Done) made it possible to remove the task from the daemon, even though the process hasn't been handled yet.

The daemon would then go ahead, handle the child process, expect the respective task to still exist and crash hard.

I still couldn't reproduce the problem myself, but the code definitely allowed this to happen and it matches your problem and example perfectly.

Thanks a lot for the detailed bug report!

If you have the time, it would be awesome if you could try to reproduce the bug on the latest master version and confirm that the bug has been fixed :)

[gotbletu]

Works fine now. no more crashy
0.7.3-alpha.0

Thank you

[Nukesor]

Perfect! Thanks a lot for the bug report and verifying that it has been fixed :)