|
Home > Archive > Unix Programming > March 2007 > Why would a person want to ignore SIGINT?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why would a person want to ignore SIGINT?
|
|
| K-mart Cashier 2007-03-03, 1:21 am |
| This isn't a homework question. This is something I've seen some Unix
programmers do. I really can't think of any reason why a person would
intentionally do this.
Chad
| |
| Logan Shaw 2007-03-03, 1:21 am |
| K-mart Cashier wrote:
> This isn't a homework question. This is something I've seen some Unix
> programmers do. I really can't think of any reason why a person would
> intentionally do this.
Well, maybe this is a contrived example, but it seems valid nonetheless.
Suppose you write a program that fork()s into 1 supervisor process and
5 worker processes, and suppose the worker processes regularly and
frequently check with the supervisor to request more work units. You
want to support exiting via a signal, but the design of the workers
could be cleaner if you assume they exit only when told to by the
supervisor process. (And maybe it's not critical but is still
helpful if they can complete the work unit that's in progress.)
Now, if you run this program from a normal Unix shell, all 6 processes
are going to end up in a process group together, and when the user hits
control-C (or whatever the intr character is), it is going to send the
SIGINT to the every process in the process group.
In this case, you'd want your supervisor process to receive the signal
but you'd want the worker processes to ignore it, since they will be
informed of it by the supervisor after they finish their work unit
anyway and since there is nothing useful they can do with it should
they receive it.
- Logan
| |
| K-mart Cashier 2007-03-03, 1:21 am |
| On Mar 2, 7:10 pm, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> K-mart Cashier wrote:
>
> Well, maybe this is a contrived example, but it seems valid nonetheless.
>
> Suppose you write a program that fork()s into 1 supervisor process and
> 5 worker processes, and suppose the worker processes regularly and
> frequently check with the supervisor to request more work units. You
> want to support exiting via a signal, but the design of the workers
> could be cleaner if you assume they exit only when told to by the
> supervisor process. (And maybe it's not critical but is still
> helpful if they can complete the work unit that's in progress.)
>
> Now, if you run this program from a normal Unix shell, all 6 processes
> are going to end up in a process group together, and when the user hits
> control-C (or whatever the intr character is), it is going to send the
> SIGINT to the every process in the process group.
>
> In this case, you'd want your supervisor process to receive the signal
> but you'd want the worker processes to ignore it, since they will be
> informed of it by the supervisor after they finish their work unit
> anyway and since there is nothing useful they can do with it should
> they receive it.
>
>
Hmmm.... This is sort of depressing because I had actually thought
about the question before I posted it on comp.unix.programmer. I think
what is perhaps
even more depressing is the fact Logan's example never once occurred
to me. Had this been a job interview question, I think the interview
would have ended
right then and there,
|
|
|
|
|