You were told it was a Windows issue, and you contradicted that.

No I wasn't. And no I didn't.

I was told: "Windows has no signals. Not even SIGALRM.". And I demonstrated that Perl's alarm implementation works for some things.

If afoken's post was meant to be interpreted as:

Perl::Unsafe::Signals will not help the OP because he is using *nix, and alarm does successfully interrupt IO on *nix."

then it would be a lot quicker & simpler if he said exactly that!

I showed that it is a Windows issue.

What "it"?

You responding to this demonstration that alarm functions under windows, with this demonstration of a pair of perl one-liners running under *nix, producing a mysterious piece of text "Alarm clock" simply makes no sense.

In the context of the post to which you responded, the content of your post is like responding to the question: 'What time is it?', with 'Thursday comes before Friday'. Not incorrect, but a total non sequitur.

Had you posted that post as a response to this one, it would--with suitable additional annotation--have made some sense. Maybe.

But, you seem to loose all sense of context in your urgency, and so simply create confusion. But that's what arises when you loose sight of what the purpose of the thread, and this place, is. Ie. helping the OP.

I wonder, have either of you considered, given your own expressed uncertainties regarding the content & function of the OPs code, if my suggestion to the OP: "You may find the use of Perl::Unsafe::Signals worth testing." is really such bad advice?

Given the OPs description of the processing he is trying to interrupt.

1. Is unlikely to be taking more than 120 seconds.
2. Ditto.
3. As you've pointed out, although this step might take more than 120 seconds, on the OPs platform alarm should successfully interrupt LWP, so it is unlikely that is the source of the OPs problem.
4. So that leaves: "Then abstract the site(domain) page information".

   Are you (both) so 100% positive that processing couldn't include some long running opcodes that would not be interrupted whilst deferred signals are in force, but might be interrupted when they are not?

And if you are not--and how could you be!--then is it not "worth" the OPs time to "test" the possibility?

And when you've reached the only possible conclusion that there is the possibility that the use of that module just might solve the OPs problem, than you'll also have to conclude that it was worth my suggesting it.

And also that all your jumping up and down, misinformation and misdirection in this sub-thread serves no good purpose. It certainly doesn't do anything to help the OP.