p5pRT
commented
10 years ago From d.white@imperial.ac.uk
Created by d.white@imperial.ac.uk
This is a bug report for perl from d.white@imperial.ac.uk\, 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:
www.nntp.perl.org/group/perl.perl5.porters/2006/12/msg119236.html
[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.
Migrated from rt.perl.org#123188 (status was 'open')
Searchable as RT123188$