At 09:37 PM 1/10/2007 -0700, Jack D wrote:
>My mistake! You said you wanted the **Edit** menu disabled. Easy - just
>increase the index to 2. It is documented that the "pattern" search for
>indices needed work, so I would just keep track of your index numbers and
>use them instead. Here is the full
At 05:39 PM 1/26/2007 -0800, Jan Dubois wrote:
>It doesn't. It will not interrupt a blocking system call. For example
>you cannot use alarm() to get a timeout for reading a socket, or reading
>from a pipe etc.
I take it that's a kernel limitation. Any word on sigalarm functionality in
Vista?
On Fri, 26 Jan 2007 20:29:38 -0500, [EMAIL PROTECTED] (Chris Wagner)
wrote:
>At 11:54 AM 1/27/2007 +1100, Sisyphus wrote:
>>The alarm() function now works on Windows:
>
>Yes but I believe it doesn't work in all circumstances. I don't remember
>seeing anything about Windows having an all working a
At 11:54 AM 1/27/2007 +1100, Sisyphus wrote:
>The alarm() function now works on Windows:
Yes but I believe it doesn't work in all circumstances. I don't remember
seeing anything about Windows having an all working alarm function.
--
REMEMBER THE WORLD TRADE CENTER ---=< WTC 911 >=--
"
- Original Message -
From: Chris Rodriguez
To: perl-win32-users@listserv.ActiveState.com
Sent: Saturday, January 27, 2007 8:35 AM
Subject: checking for infinite loops
> The alarm function seemed to be the way to go - but not with Windows.
The alarm() function now works on Windows:
I would start by executing the sub program in a seperate thread. That way
the main thread can keep an eye on it and decide if it's run too long and
then do something about it. Another way to do it is with Win32::Process and
then kill them after some time span.
At 01:35 PM 1/26/2007 -0800, Chris
Hello,
I have a program that runs other programs (through require statements and
what not). There's a problem in that some of these sub-programs may have
infinite loops, which would cause the main program to hang. I'd like the main
program to just detect such and go on to the next one.
