TaskPool tries to reuse the panicked task, thus dies

[barosl]

Consider the following example:

use std::sync::TaskPool;
use std::io::timer::sleep;
use std::time::duration::Duration;

fn main() {
    let mut pool = TaskPool::new(5, || { proc(id: uint) { id } });

    pool.execute(proc(id: &uint) panic!("!! at Task #{}", id));
    sleep(Duration::milliseconds(10));

    loop {
        pool.execute(proc(id: &uint) println!("Task #{}", id));
        sleep(Duration::milliseconds(10));
    }
}

We make the first task in the pool panic!(). It results the task to die, and the associated channel becomes unusable.

After a while, in the infinite loop, TaskPool chooses the first task (which is dead) again and tries to reuse it. However, the channel as well as the task is not available. So, the main task panics like this:

task '<unnamed>' panicked at '!! at Task #0', test.rs:8
Task #1
Task #2
Task #3
Task #4
task '<main>' panicked at 'sending on a closed channel', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsync/comm/mod.rs:571
task '<main>' panicked at 'sending on a closed channel', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsync/comm/mod.rs:571
stack backtrace:
   1:     0x7f3f3c383dd0 - rt::backtrace::imp::write::h8a05a2225574bd5ascq
   2:     0x7f3f3c386c50 - failure::on_fail::h3903c5b5788bc95c3xq
   3:     0x7f3f3c3942a0 - unwind::begin_unwind_inner::h0919efe752d6fd357Rd
   4:     0x7f3f3c393f20 - unwind::begin_unwind_fmt::hd089b86912964a95zPd
   5:     0x7f3f3c393ee0 - rust_begin_unwind
   6:     0x7f3f3c3c5500 - panicking::panic_fmt::h57475b82a3c609a1x7j
   7:     0x7f3f3c3c5240 - panicking::panic::h695f69b4c28a75e0B4j
   8:     0x7f3f3c3438f0 - comm::Sender<T>::send::h14935566101124425183
   9:     0x7f3f3c3475d0 - sync::task_pool::TaskPool<T>.Drop::drop::h11194483048085865320
  10:     0x7f3f3c347540 - std..sync..task_pool..TaskPool<uint>::glue_drop.2909::h08736b903b89c2b2
  11:     0x7f3f3c332d70 - main::he6e3314dedd67115haa
  12:     0x7f3f3c37b7a0 - start::closure.8531
  13:     0x7f3f3c394e10 - rust_try_inner
  14:     0x7f3f3c394e00 - rust_try
  15:     0x7f3f3c392460 - unwind::try::h32143614f9ac9c88PGd
  16:     0x7f3f3c392300 - task::Task::run::h8c90cb04437a131dFMc
  17:     0x7f3f3c37b4c0 - start::hd7eedac68fc68d83Yje
  18:     0x7f3f3c37b430 - lang_start::h6d3cacf2b5551a44hje
  19:     0x7f3f3c332e90 - main
  20:     0x7f3f3b727dd0 - __libc_start_main
  21:     0x7f3f3c332c40 - <unknown>
  22:                0x0 - <unknown>
task failed during unwinding. aborting.
zsh: illegal hardware instruction (core dumped)  ./test

Is this intended? Or is it just a bug?

[steveklabnik]

This was brought up on Reddit today http://www.reddit.com/r/rust/comments/2ltjwm/a_loadbalancing_taskpool_resistant_to_child_panics/

[barosl]

Oh, that post was on Reddit! It was me that broke the Iron server, so I asked @reem if he could fix it, and he did it amazingly. So I wanted to talk about the issue on GitHub.

Should I close this issue in favor of the Reddit post? Or is it better to be closed after the problem is resolved?

[steveklabnik]

I have no idea what the plan is, but it does seem like this behavior is poor. Let's leave this open.

[barosl]

Resolved by #18941.