GLI: Better way of terminating Wget?

[ak19]

The TERM and INT signal handlers on Linux do a proper job of terminating wget prematurely (when the user presses the stop download button in GLI or when CTRL-C is entered into the console in the middle of running downloadfrom.pl using a WgetDownload.pm-based downloader). The INT signal handler in WgetDownload.pm also works on Windows to terminate wget when the perl script is run from a console.

However, on Windows, the TERM handler is never called when Java does a process.destroy() upon the stop button being pressed. Other issues on Windows include the fact that the perl scripts only have access to pseudo-pids (which mean nothing to other perl scripts launched to kill wget using these pseudo-pids). Since signal handling did not work through Java/GLI on Windows, we resorted to polling the STDIN of perl to which the Java program would write when it was time to terminate wget. However, this was doing blocking IO (non-blocking IO with IO::Select did not work on Windows though it worked on Linux, see ​http://www.perlmonks.org/?node_id=651768 ). An attempt at using a separate thread to monitor STDIN did not work. Also, I assumed that it would still be heavy on the CPU because I thought that it would be continuously polling STDIN.

The currently implemented solution is for the Java program to write out a file when it's time to stop wget. The perl script will be forever checking for the existence of this file and kill wget when it finds that the file has appeared. While it works, this continuous polling places a huge load on the CPU.

While I could not get multithreading a similar solution to work on Windows earlier, it seems that multithreading may be a better option that the current temporary fix. Oran stated that a tutor told him that while waiting for input is a blocking operation, it is not a CPU-intensive one since IO signals are interrupts, not continuous polling operations.

It may be good to attempt implementing the termination of wget in WgetDownload.pm using this last solution again (multithreading).