in reply to Perl alarm not going off when local websocket connection is active

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.

Replies are listed 'Best First'.
Re^2: Perl alarm not going off when local websocket connection is active
by cavac (Prior) on May 05, 2025 at 14:45 UTC

    Cyclic callbacks might also be an option. My guess is those are already implemented in some way to handle the cyclic nature of the game logic (if it's one of those real time games). So setting a player state for "is in timeout since..." and checking that in the cyclic callback could also be an option.

    Additionally, in my own software, i send regular messages (pings) in both directions. This keeps the connection open (especially on NATed networks), and also provides the functionality to check for application timeouts. (Just because a connection is open doesn't mean the application at the other end still functions correctly).

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
    Also check out my sisters artwork and my weekly webcomics
Re^2: Perl alarm not going off when local websocket connection is active
by jagordon59 (Initiate) on Apr 29, 2025 at 18:50 UTC
    Thanks for your insight. I'll check to see if that is possibly the case and post more about the framework here if I don't uncover anything on that.
      Well what framework is it? Does it offer its own timer function?