Behavex runner gets stuck indefinitely when a test case terminates with sys.exit/seg fault

[lazareviczoran]

Describe the bug
Hello, we ran into a case where we noticed that the runner gets stuck while running the test cases when one of the test processes ends unexpectedly. We tried to dig into this and figure out why this behavior is occurring, and we noticed that there is an open bug in the multiprocessing.Pool where if the function that is being executed as a subprocess ends with a sys.exit/seg fault, the process will get stuck on the join part indefinitely. Seems like the concurrent.futures.ProcessPoolExecutor has this specific issue fixed, not sure if there would be some other side effects that would break the current behavex behavior, but it might be worth looking into it.

To Reproduce
Steps to reproduce the behavior:

1. Run the following code snippet (with the multiprocessing.Pool) to get the current behavior (the pool getting stuck, but all 10 subprocesses will ran)

import multiprocessing
import sys

def func_that_exits():
    sys.exit(0)

process_pool = multiprocessing.Pool(3)

for i in range(10):
    process_pool.apply_async(func_that_exits, ())

process_pool.close()
print('joining')
process_pool.join()
print('joined')

2. Run the following code snippet (with concurrent.futures.ProcessPoolExecutor) to get the behavior where the main process won't get stuck, but only 3 "subprocesses" will run

from concurrent.futures import ProcessPoolExecutor
import sys

def func_that_exits():
    sys.exit(0)

process_pool = ProcessPoolExecutor(3)

for i in range(10):
    process_pool.submit(func_that_exits)

print('joining')
process_pool.shutdown()
print('joined')

Expected behavior
In case any of the test cases exits with a seg fault or a sys.exit, the runner should exit instead of hanging indefinitely.

Desktop (please complete the following information):

• OS: linux/macOS
• Browser: not relevant
• behavex version: 2.0.1

[jbridger]

Hi @hrcorval!

As this was causing us issues, we wanted to have an attempt at addressing it and providing additional debug information.

Would be great if you could have a look at our PR on this: #120

Thanks 🙂