So it's unreliable. alarm(2) doesn't interrupt blocking I/O on MSWin32, so 'timeout' won't do that either.

So that's new information, thanks, I only knew about problems coming from using alarm-based functions inside block - like using sleep...

So to conclude - general solution is the one I described initially, it has known deficences - namely problems with reliability ( thus, there are no solutions to my question about "reliable" way to do that ). On Unix you can expect lost signals, side effects from 'sleep' and 'alarm' used inside the block. On MS you can additionally expect haning on blocking I/O (which is what you're usually trying to detect with timeout).

So it's unreliable. alarm(2) doesn't interrupt blocking I/O on MSWin32, so 'timeout' won't do that either.

alarm() is a unix'ism and it works in other languages like C under Unix just fine. Just because it isn't implemented properly (probably by MS) doesn't mean it is broken. Assuming alarm doesn't work for you then you may want to try something like forking a child process, let it perform the work and return the results, and have the parent send it a kill if it doesn't return in a reasonable period of time.

So I conclude that esteemed perlmonks don't know solution to that problem. pity.

And you've come to this conclusion by reading through all of the previous posts about this problem? What new issue have you come up with that hasn't been discussed in the past?

Alarm is not supposed to work reliably. And it doesen't work reliable neither with perl nor with C.

Please check your facts.

Have you heard about something called 'POSIX Signals'? Do you know that one of main differences between those and normal unix signals is reliability?

And yes, none of the comment contain any answers, unless you count as an answer to reliably comment from a saint telling me to use '\n' in die. And then backtracking and saying that one shouldn't use 'die' at all.