From @lizmat

Created by @lizmat

If you try to do alarms within a thread, and $SIG{ALRM} was not
assigned in the main thread previously, an alarm() that goes
off in the thread will bomb the program completely with the
mysterious message

Alarm clock

being sent to STDERR. It bombs in such a way that I'm not able
to get valgrind to give me a trace (yet).

This behaviour can be circumvented by assigning $SIG{ALRM} with
something (except the empty string) in the main thread before
the thread starts.

Further investigations reveal that assigning in a surrounding
thread that is not the main thread, does _not_ work, it _must_
be the main thread. However, other threads _may_ be running
before the $SIG{ALRM} is set in the main thread, but of course
these threads can not use alarm() reliably then.

This shows it all​:

# alarm.pl
use threads;
$SIG{ALRM} = 'a' if @ARGV; # must assign outside of threads
threads->new( sub {
$SIG{ALRM} = sub { die "alarm went off properly\n" };
eval {
alarm( 3 );
1 while 1;
alarm( 0 );
};
warn "\$\@ = $@";
} )->join;

  $ perl alarm 1
  $@​ = alarm went off properly

  $ perl alarm
  Alarm clock

Flags:
     category=core
     severity=medium

Site configuration information for perl v5.8.0:

Configured by liz at Tue Aug 20 12:44:35 CEST 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
   Platform:
     osname=linux, osvers=2.4.18, archname=i686-linux-thread-multi
     uname='linux echt.dijkmat.nl 2.4.18 #8 smp mon mar 25 22:28:36 cet 
2002 i686 unknown '
     config_args='-de -Dusethreads'
     hint=recommended, useposix=true, d_sigaction=define
     usethreads=define use5005threads=undef useithreads=define 
usemultiplicity=define
     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
     use64bitint=undef use64bitall=undef uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/include/gdbm',
     optimize='-O2',
     cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing 
-I/usr/local/include -I/usr/include/gdbm'
     ccversion='', gccversion='2.96 20000731 (Red Hat Linux 7.1 2.96-98)', 
gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
     alignbytes=4, prototype=define
   Linker and Libraries:
     ld='cc', ldflags =' -L/usr/local/lib'
     libpth=/usr/local/lib /lib /usr/lib
     libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
     perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
     libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
     gnulibc_version='2.2.4'
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
     cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:



@INC for perl v5.8.0:
     /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
     /usr/local/lib/perl5/5.8.0
     /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
     /usr/local/lib/perl5/site_perl/5.8.0
     /usr/local/lib/perl5/site_perl/5.7.3
     /usr/local/lib/perl5/site_perl
     .


Environment for perl v5.8.0:
     HOME=/home/liz
     LANG=en_US
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
     PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/liz/bin
     PERL_BADLANG (unset)
     SHELL=/bin/bash

From green@FreeBSD.org

I'm noticing the same thing on FreeBSD with local $SIG{ALRM} assignment
instead of in a thread. There seems to be another bug that occurred
just like this long ago on 5.6.0 and was fixed; maybe there was a reversion.

From @jhi

I must point out that saying "getting alarm() to work with threads" is very
similar to saying "getting TNT to work with Semtex". Signals and threads
are rather poorly mixing concepts, some things are defined in standards
about the interaction but what is defined is usually pretty unhelpful, like
for example that the when a signal arrives IT MAY ARRIVE AT ANY THREAD.
The main thread, the thread who send the signal, ANY THREAD.
In other words, I think we may be out of luck here.

From @lizmat

At 15​:42 +0000 2/6/03, Jarkko Hietaniemi (via RT) wrote​:

I must point out that saying "getting alarm() to work with threads" is very
similar to saying "getting TNT to work with Semtex". Signals and threads
are rather poorly mixing concepts, some things are defined in standards
about the interaction but what is defined is usually pretty unhelpful, like
for example that the when a signal arrives IT MAY ARRIVE AT ANY THREAD.

Too bad. However, it does seem to work under Linux... but that's
only because threads are actually processes there, yes I know....

The main thread, the thread who send the signal, ANY THREAD.
In other words, I think we may be out of luck here.

This is really too bad, as there are particular applications that you
would want to do parallelly with threads because of timeouts, such as
resolving IP numbers. In my experience, gethostbyaddr() can hang
indefinitely (well, longer than I cared to wait anyway), which you
would like to catch() with an alarm().

I guess I will need to spend some more time on forks.pm again... ;-)

Liz

From @schwern

0 ~$ bleadperl ~/tmp/test
Alarm clock
0 ~$ bleadperl ~/tmp/test 1
...hang...

Is that an improvement? :) That's bleadperl@​25129 on OS X 10.3.9

From @lizmat

To be quite honest, I've given up on threads in Perl 5.

Signals and threads in Perl are the Wild West, really, last time I checked....

This issue can be closed as far as I'm concerned.

Signals and threads in Perl are the Wild West, really, last time I checked....

Quite so, I'm afraid.