My main workstation has mostly fairly to very current software on it, but it is running on top of a Linux install that, while for the most part constantly maintained, is built on very old underpinnings (it was originally a Slackware 7.0 install, still runs on a 2.4 kernel).  Due to accumulated cruft and bitrot, I've been working towards doing a clean reinstall using Gentoo 10.0.  My last obstacle to doing this was my preferred music player, DigitalDJ, which is long since abandoned and won't even configure, let alone compile, on any current Linux distribution.  So, naturally, I wrote a clone of it in Perl.

My new music player, provisionally named PerlDJ, uses a PerkTk GUI mostly consisting of a Tk::MListbox.  It uses ualarm(50) and a SIGALRM handler to perform background tasks (including advancing through its playlist and listening for commands on its remote-control FIFO) while the UI is waiting for input.  On my Slackware-7-based desktop machine, it works ALMOST perfectly.  (That 'almost' will be covered in a moment.)  However, on my Gentoo 10.0 laptop with 2.6 kernel, it appears to be blocking in the Tk MainLoop().  It will start playing a single song, but then will neither advance to the next song, update its UI, or obey remote-control commands until some event — a mouse move, a focus change, a window expose or window map — happens in its window.  Even just switching from one fvwm2 virtual desktop on which the player is not mapped, to another on which it is also not mapped, will unblock it.  Any UI event seems to be good for about 15-20 SIGALRMs.  Also, on the Gentoo laptop only — never on the desktop — the application goes into an infinite loop on exit.

Now, I said "ALMOST perfectly".  Sometimes, very very occasionally, maybe a couple of times a day, the player will also block on the desktop machine.  Again, as little as a window expose event or virtual desktop change is sufficient to unblock it.  I ASSUME this is the same problem manifesting, but have not been able to figure out any way to verify it, as it's a true Heisenbug — you cannot simultaneously observe it, and measure it.

The puzzle here, to me, is why is it behaving so differently on the two machines?  Why does it very occasionally block on my desktop?  Why does it ALWAYS, 100% consistently, block on my laptop?

The laptop is running Perl 5.10.0 i686-linux-thread-multi-64int-ld, compiled with MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LONG_DOUBLE USE_PERLIO USE_REENTRANT_API, with PerlTk version 804.028 and tk-8.4.7.  The laptop has Perl 5.10.1 i686-linux-thread-multi, compiled by the Gentoo ebuild with MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API, also with PerlTk 804.028, and with Tk 8.5.7.  In both cases, Tk is compiled with threading enabled.  (The player application is single-threaded, but I mention this for completeness.)  What little I do know is that while the UI is active (including drawing its window and loading its playlist into the MListbox), it continues to handle and respond to SIGALRMs, but about the time that playlist loading completes, it stops responding to SIGALRMs, and thence responds to them only when something happens in the UI.

I still don't know why MainLoop() is blocking signal handling on the Gentoo machine but not on the Slackware-based machine.  However, I was able to solve the problem by removing the ualarm() and SIGALRM trap, and replacing them with a Tk $MainWindow->repeat() timer calling my SIGALRM handler function.

The moral of the story, in a nutshell:  Tk $MainWindow->repeat() timers in a Tk application are reliable; ualarm()/SIGALRM is not.