Re: Suggestions on differentiating child processes

Not a great suggestion but you could do something like

$SIG{__USR1__} = sub {
  open(my $f, ">/tmp/taskinfo");
  print $f "$$'s current task is $TASK\n";
  close($f);
}
[download]

then just make sure each process sets $TASK correctly and do

> kill -USR1 12345
> cat /tmp/taskinfo
12345's current task is making breakfast
[download]

Could be dangerous on perls where signals are not safe (pre 5.8 I think)

Comment on Re: Suggestions on differentiating child processes Select or Download Code

Replies are listed 'Best First'.
Re^2: Suggestions on differentiating child processes by steves (Curate) on Nov 12, 2004 at 18:15 UTC
I agree that's another good one. It's something a number of standard *nix processes do -- dump run-time info. on receipt of a specific signal. I also worked on a system that had logging similar to what I use now (level based logging with the ability to set that globally or per package). We added a signal catcher that toggled the highest level of logging off and on globally. That way we could trace what was going on at specific points in time as needed. I've also thought that if you have some sort of fixed settings whose values change as you run, that a good model would be to make that accessible via shared memory while the process is running, where the shared data drives a dashboard sort of view of what's going on. You could also use a database for that sort of thing although that might add a bit of overhead. If properly set up, shared memory would also offer the possibility of making the settings externally accessible; e.g., you might be able to set a trace level in the shared memory that drives what resolution of data you get to see in the shared data area.	[reply]
Re^2: Suggestions on differentiating child processes by gnu@perl (Pilgrim) on Nov 12, 2004 at 18:01 UTC
Very good idea! Thanks. This might be the simplest idea. Nice and creative, thanks.	[reply]