Avoiding mp.Pool in case of using only 1 worker for easier pdb debugging

Problem: When debugging QONNX model transformations which can make use of applyNodeLocal using pdb, the use of multiprocessing.Pool stops the debugger from being able to stop at the exact stack frame which is created by the process forked using the multiprocessing library if the error happened there.

The stack frame can still be accessed by breakpointing right before the actual error occurs, however this would require prior knowledge of where the code breaks, which can be highly undesirable.

Solution: Intuitively, the user would expect that if they simply set their num_workers to 1, that multiprocessing will not be called and pdb will work as expected. Thus, I propose to simply check for this case and run the applyNodeLocal() function 'as is' without mp.Pool if the worker count is set to 1.

fastmachinelearning / qonnx

Avoiding mp.Pool in case of using only 1 worker for easier pdb debugging #127