ualarm(time, interval) should wait interval microseconds and send
an alarm, but it seems that maybe interval is treated as
milliseconds instead.
Also, select is not interrupted by SIGALRM, but it should be.
Also, sleep is interrupted by SIGALRM in the app, but not in the
MPW tool.
Logged In: YES
user_id=37219
Chris, could you re-verify this, the filing is pretty old:
- Not sure where you found ualarm (could you give me a demo
script), couldn't test.
- select() worked on GUSI level, could you give me a simple
Perl script if it's still a problem.
- sleep now seems to be interrupted properly in the tool
date; perl -e '$SIG{ALRM} = 'IGNORE'; alarm(5); sleep(10);';
date
Logged In: YES
user_id=3660
I don't recall what happened when I reported this (it was
along time ago), but I can report that I see no problem with
sleep in the tool, and that select is properly being
interrupted.
date; perl -e '$SIG{ALRM} = sub {}; alarm(5); sleep(10);'; date
date; perl -e '$SIG{ALRM} = sub {}; alarm(5);
select(undef,undef,undef,10);'; date
Shrug. So I guess those are fine. Odd.
After more testing, using Time::HiRes' test suite, all of my
current problems exist in:
* Needing to reinstall signal handlers after use
* ualarm's interval apparently occurring in milliseconds,
not microseconds
The first one you will think about; the second, I think
happens in GUSIAlarm::Restart. It is multiplying the value *
1000, which seems wrong, and would explain the behavior.
Here's the test script:
#!perl -wl
use Time::HiRes qw(ualarm time);
my $tick = 0;
sub tick {
$tick++;
print time();
$SIG{ALRM} = \&tick;
}
$SIG{ALRM} = \&tick;
print time();
ualarm(10_000, 10_000);
sleep while $tick <= 3;
ualarm(0);
__END__
In Mac OS X, I get:
1035840274.11679
1035840274.12925
1035840274.13961
1035840274.14923
1035840274.15924
In MacPerl, I get:
3118667091.0467
3118667091.20997
3118667101.2042
3118667111.20832
3118667121.20414
The same thing happens with Time::HiRes::alarm, too. An
interval of .005 seconds lasts 5 seconds, .01 seconds lasts
ten seconds, etc.
Logged In: YES
user_id=3660
Passes tests now.