Just an early pre-caffeine hunch but if I'm reading your description correctly what's prossibly happening is that you've got multiple connections all calling this code and diddling the $SIG{ALRM} setting to heir own (different) coderef which winds up clobbering the others. There's only one signal handler per signal per process / signal handling thread (threading making things much more interesting maybe) on *NIX. Possible scenario might be if you have more than one connection and you happen to get two disconnections in a row; the first disconnect to fire (say for Bob) sets up the handler, but before it runs a disconnect for Egon comes in and changes the ALRM handler to call for him and Bob's not your uncle (he's instead a zombie connection in your player hash because the handler never ran to clear him out).
You don't specify what module or framework but usually things like this are written using some sort of event loop which is supposed to be the thing handling signals and timeouts and what not. Rather than you directly handling the $SIG{ALRM} yourself those will usually provide a mechanism to register callbacks and timeouts that will be triggered by the framework in a way that won't clobber other settings. My description's a bit handwavy and general but if you provide a bit more details (what web framework is in use) I bet someone will be able to give concrete examples.
The cake is a lie.
The cake is a lie.
The cake is a lie.
In reply to Re: Perl alarm not going off when local websocket connection is active
by Fletch
in thread Perl alarm not going off when local websocket connection is active
by jagordon59
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |