Re^2: Handling badly behaved system calls in threads

I came across this idea in digging through the archives (the exact posts or Perl documentation escape me) but thought it was not worth implementing since all calculations, good and bad, should be in the same process group as perl - I used threads and not fork for my model. Was I incorrect in this assumption? At any given time, I might have 20 calculations running and bad cases are a fraction of a percent of the total.

Comment on Re^2: Handling badly behaved system calls in threads

Replies are listed 'Best First'.
Re^3: Handling badly behaved system calls in threads by ikegami (Patriarch) on Sep 04, 2010 at 20:57 UTC
You're implying that if you use fork (i.e. create child processes), the workers won't be in the same process group. That's not true. A process group is a group of processes, not a group of threads. (Mind you, all your threads will be in the same process group by virtue of being in the same process.) `if (!fork()) { sleep; exit(0); } if (!fork()) { sleep; exit(0); } kill TERM => $$; # Only kills self` [download] `if (!fork()) { sleep; exit(0); } if (!fork()) { sleep; exit(0); } kill -TERM => $$; # Kills all three processes` [download]	[reply] [d/l] [select]
Re^4: Handling badly behaved system calls in threads by kennethk (Abbot) on Sep 07, 2010 at 15:56 UTC
Sorry, upon rereading I see I expressed myself poorly. I meant to say that I need to be able to kill one and only one lineage of processes. At any given time, I may be executing 20 different threaded tests within the main executable. Each test will create a child (the shell) and a grandchild (the badly-behaved executable). I was concerned that if I killed the process group (changing the main's pgid to avoid the axe), all currently running executables, not just the failing one, would be killed. Hence, killing the process group would mean one failing test may take 19 good ones out with it. Please correct me if I am ill-informed.	[reply]