On Tue, Oct 4, 2016 at 2:07 PM, X Dungeness wrote:
> Here's a possibly relevant note in the docs for both "alarm" and
> "sleep":
>
> It is usually a mistake to intermix "alarm" and "sleep" calls,
> because "sleep" may be internally implemented on your system
> with "alarm".
>
>
>
It
Here's a possibly relevant note in the docs for both "alarm" and
"sleep":
It is usually a mistake to intermix "alarm" and "sleep" calls,
because "sleep" may be internally implemented on your system
with "alarm".
On Tue, Oct 4, 2016 at 1:34 PM, Chas. Owens wrote:
> The first alarm
The first alarm is in a different process (same PID different process) due
to the exec. I am not sure what is happening, but in general it is never a
good idea to do anything complex in a signal handler.
On Tue, Oct 4, 2016 at 4:21 PM Shawn H Corey wrote:
> On Tue, 04 Oct 2016 19:32:44 +
>
On Tue, 04 Oct 2016 19:32:44 +
"Chas. Owens" wrote:
> It looks like the problem exists at the C level as well. This code
> doesn't work past the first alarm:
Doesn't it say the alarm has to be reset by the code in the
documentation? After all, you don't want a second alarm to go off
before
It looks like the problem exists at the C level as well. This code doesn't
work past the first alarm:
#include
#include
#include
#include
#include
int n;
char s[10];
char* prog;
int alarm_called = 0;
void handle_alrm(int signo) {
if (signo == SIGALRM) {
execv(prog, (char*[]) { prog, s, NU
First, never use -w flag to enable warnings; use the warnings pragma
instead.
Second, you should not exec the script directly, you don't know if it is
executable or not, and it could even wind up running under a different
version of perl. Instead, you should exec same the interpreter that is
runn
