Interesting approach, tailing configfile.log

The example with the alarm was just an example trigger, to show you how you can re-read the configuration. You can get rid of it now, as you have a trigger (configfile.log)

Say you have four files to watch, namely file A, ... file D. You create for each one of them a Wheel, that you store in $_HEAP->{'watchers'}. I'd suggest you keep the wheels like: $_HEAP->{'watchers'}->{'A'} .. $_HEAP->{'watchers'}->{'D'} etc.

This way, when you send the event that the configuration file has changed, a subroutine checks the new file names to tail. Say you need to watch now file A, file B, file E and file Z. The subroutine will keep the wheels stored in $_[HEAP]->{'watchers'}->{'A'} and $_[HEAP]->{'watchers'}->{'B'}, deletes the wheels watching files C and D, and creates new wheels for files E and Z

The whole point is that you are keeping the Wheels alive, by having a reference to them in the $_[HEAP]. As soon as you delete a reference to one wheel from $_[HEAP], $poe_kernel will do the clean-up for you (in case there are no more events for it to be delivered or there is no other reference to them).

There are other methods too to keep sessions alive, Here's another example

In short, you don't need to restart the $poe_kernel. It's main purpose is to live forever ;-) But you may "restart" wheels by deleting, recreating them as needed.