use signal.signal() on Windows

[zrquan]

Fix #1423

[shelld3v]

@zrquan Hey are you sure this works well? Cause I thought back then that if we used signal.signal then all the exception handlers wouldn't receive the exception calls from self.handle_pause right? Even though it did work well in my tests but I still couldn't figure out why it worked and would there be any issue.

[shelld3v]

And if we can make sure that signal.signal works perfectly well then I don't see why we shouldn't do the same to Linux and even the default "threads" mode

[zrquan]

@shelld3v You’re right, this doesn’t work on Windows—I got a bit lazy and didn’t test it there since I’m on Linux. 😰

do the same to Linux and even the default "threads" mode

I submitted a new PR #1439 following your advice.

[zrquan]

And I found a bug in "threads" mode: when skipping the current directory to the next one, the program just exits.

Screencast_20241113_224005.mp4

[shelld3v]

@zrquan Yeah, I think exceptions raised in handle_pause can't be catched in start, so probably by far we should only use signal.signal in async mode. Bringing it to threads mode will take more than just a few lines of code

[zrquan]

I think exceptions raised in handle_pause can't be catched in start

I tested it on Linux, and it can catch exceptions just fine.

The bug I mentioned earlier happens because the "next" operation sets the fuzzer's quit_event, but it isn't cleared in the next scan, which stops the task. I fixed it in commit 82eeb84.