Skip Menu |
Report information
Id: 16807
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: elizabeth <liz [at] dijkmat.nl>
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: medium
Type:
Perl Version: 5.8.0
Fixed In: (no value)



Date: Wed, 28 Aug 2002 11:00:14 +0200
To: perlbug [...] perl.org
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: getting alarm() to work within threads
Download (untitled) / with headers
text/plain 3.9k
This is a bug report for perl from liz@dijkmat.nl, generated with the help of perlbug 1.34 running under perl v5.8.0. ----------------------------------------------------------------- [Please enter your report here] 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 ======================================================== 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 [Please do not change anything below this line] ----------------------------------------------------------------- --- 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
Download (untitled) / with headers
text/plain 217b
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.
Download (untitled) / with headers
text/plain 482b
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.
Date: Thu, 6 Feb 2003 16:53:34 +0100
To: perlbug-followup [...] perl.org
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #16807] getting alarm() to work within threads
RT-Send-Cc:
At 15:42 +0000 2/6/03, Jarkko Hietaniemi (via RT) wrote: Show quoted text
>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.... Show quoted text
>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
Download (untitled) / with headers
text/plain 712b
Show quoted text
> [elizabeth - Wed Aug 28 02:01:38 2002]: > > This shows it all: > > == alarm ======================================================== > 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
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
Subject: Re: [perl #16807] getting alarm() to work within threads
Date: Thu, 14 Jul 2005 11:25:02 +0200
To: perlbug-followup [...] perl.org
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Download (untitled) / with headers
text/plain 954b
At 1:38 AM -0700 7/14/05, Michael G Schwern via RT wrote: Show quoted text
> > [elizabeth - Wed Aug 28 02:01:38 2002]:
>> >> This shows it all: >> >> == alarm ======================================================== >> 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
> >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
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 service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org