|
Re: Monitoring child threads
by TOD (Friar) on Jan 24, 2008 at 12:55 UTC
|
if you're really talking about threads and not processes, the SIGCHLD advice would be rather senseless. in this case you should consider implementing a handler for $SIG{__DIE__} in your main thread and localizing a hook for it in the child threads. e.g.:
# main thread:
sub sig_die_handler {
my $message = shift;
warn $message;
}
[...]
# child threads:
local $SIG{__DIE__} = sub { &::sig_die_handler(shift) };
or something like that. anyway, this is roughly the way to achieve what you have in mind - if we're really talking about threads.
--------------------------------
masses are the opiate for religion.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
We are talking about detached threads which communicate via queues(Thread::Queue) to each other.
| [reply] |
Re: Monitoring child threads
by zentara (Cardinal) on Jan 24, 2008 at 14:09 UTC
|
Since you are using sockets in threads, you can probably use the fileno of the socket to monitor when a thread controlling a socket dies. Threaded apps, automatically share the fileno's of the sockets. See Gtk2 Interactive Chat client for ideas. The socket-filehandle code there, is GLib based, so you can remove the Gtk2 gui and run it as a command-line threaded app.
| [reply] |
Re: Monitoring child threads
by BrowserUk (Patriarch) on Jan 24, 2008 at 14:49 UTC
|
Currently the programming is not effectively watching when one of the child threads dies.
Do you mean dies with an exception, or terminates because it's finished?
Do you want to know for any thread, or for each given thread?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
At the moment a crash of a child thread only leads to console message.
The minimum is that the program terminates - the maximum is a more complex handling depending on the terminating thread.
I would like to have a different handling for incoming threads than outgoing threads, but this is the second step.
| [reply] |
|
|
sub thread {
eval{
## code
} or ##handle error.
}
If you can trap the error, you can then pretty much do anything that you need to do.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Re: Monitoring child threads
by roboticus (Chancellor) on Jan 24, 2008 at 12:25 UTC
|
weismat:
I'd suggest making a signal handler for SIGCHLD, then your handler could examine the data structures owned by the child and look for an error state. So your child can set its state to "IDLE" until it gets a job, then set its state to "WORKING", and then "IDLE" when the job ends. Finally, set the state to "DONE" before terminating normally. If you get a SIGCHLD and the child isn't in "DONE" state, it's an error.
I'd suggest ignoring this node, as it's completely wrong, as indicated by TOD below...
...roboticus | [reply] |
|
|
Great suggestion, but unfortunately I am running this program either on Linux or Windows - I guess I could use a different signal for Linux, but it will not work for Windows.
| [reply] |
|
|
weismat:
OK, here's what I'd suggest... ;^)
Create a set of shared variables to maintain the child processes state and time of last update (like a watchdog). Then periodically wake up your main loop, and check for any thread whose last update time is too long whose state is not "DONE"....
...roboticus
| [reply] |