develooper Front page | perl.perl5.porters | Postings from November 2014

[perl #123188] SIG_PENDING_DIE_COUNT kills program in new situation

Thread Previous
James E Keenan via RT
November 13, 2014 01:41
[perl #123188] SIG_PENDING_DIE_COUNT kills program in new situation
Message ID:
On Wed Nov 12 07:09:58 2014, wrote:
> This is a bug report for perl from,
> generated with the help of perlbug 1.39 running under perl 5.18.2.
> -----------------------------------------------------------------
> As in rejected bug #112404, we have just encountered the
> SIG_PENDING_DIE_COUNT limit.  On Perl 5.18.2 on Ubuntu 14.04 linux,
> we have some locally developed highly threaded Perl code that
> controls a set of 40-80 firewalled desktop PCs in "exam mode".
> The controller manages a set of ssh connections to the client desktop
> PCs, telling them when to start into exam mode, then every N minutes
> telling them to take a copy of the local exam directory where the
> student is working, then at the end tells the PCs to exit exam mode
> and reboot.  It uses a pool of worker threads, various ": shared"
> variables, and a Thread::Queue of work-jobs (names of hosts to send
> a command to).  It does no explicit signal handling.
> This code has worked reliably across multiple Perl versions on
> multiple Ubuntu distros for approx 6 years, but on Ubuntu 14.04,
> almost immediately we hit the dreaded
> "Maximal count of pending signals (120) exceeded"
> inside Thread::Queue line 70.  This is in the dequeue()
> function where it appears to be using signals to build condition
> variables, waiting and signalling on one.
> We have rebuilt our own Perl 5.18.2 experimental version with
> #  define SIG_PENDING_DIE_COUNT 520
> and invested approximately 8 hours of time in experiments on
> 80 desktop PCs, and found that this completely resolves our issue,
> but this is a horrid kludge, given that we GUESSED the value 520:-)
> May I request that this code, the rationale for which was described
> in:
> [in summary: added in Dec 2008 to Perl 5.8.8 to fix a specific bug on
> OS/2,
> with an arbitrary limit of 120 pending signals]
> makes no sense now and should be altered, removed, or reimplemented,
> because
> it is actively breaking real code.
> One possible minimally intrusive solution would be to turn the limit
> from
> a constant to a variable and add a command line option to perl to
> allow us
> to set the limit to an arbitrary value.  We would be willing to write
> and submit such a patch if this would help.
> Best Wishes
> Duncan White
> Systems Manager,
> Computing Support Group,
> Dept of Computing,
> Imperial College London.

1. Can you suggest any way to reproduce this problem outside of your customized environment?

2. Have you ruled out the possibility that the problem lies in the version of Ubuntu you are using (which I also use) as distinct from Perl?  If so, how have you made that rule-out?

3. Is the 'perl -V' output attached to your bug report from the machine where you observed the problems?  If not, can you provide that output?

Thank you very much.
Jim Keenan

James E Keenan (

via perlbug:  queue: perl5 status: new

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About