> There's a race condition -- Can the child call signal() before the parent
> calls kill()?
Maybee that could happen, but actually it is the opposite case
that will give trouble. I guess that is what is going wrong.
Quote:> Apparently, when fork() returns under HP-UX the child process
> is placed at the front of the kernel's processor queue, while in Linux the
> parent process is runs first. So on Linux, kill() is called before
> signal().
I would guess that Linux would normally schedule the child
before the parent. That is the most efficient in many cases
where the child is going to call exec shortly.
Quote:> You could try fixing it by placing a sleep(1) before the parent's kill(),
> and increasing the child's sleep() to sleep(2). But beware, CPU scheduling
> is quirky and makes few promises.
Of course that is a way to verify the assumption about what
is going wrong. But it is not really a solution, the race is
still there.
Quote:> By the way, it's a bad idea to call printf() in a signal handler.
That is true, but in this particular case it would probably work.
I guess any signal handler interrupting sleep() or pause() can
safely work.
Quote:> Usually
> you just want the signal handler to set a flag, and then have the program
> test that flag periodically. In this example, you would have the child
> test the flag after it returns from sleep().
Right that would be better.
Quote:> #include <stdio.h>
> #include <signal.h>
> int flag;
Shouldn't this be initialized?
int flag=0;
Quote:> void abc();
Should actually take an argument
void abc(int sig);
Quote:> int main(void)
> {
> int pid;
Maybee that is pedantic, but:
pid_t pid;
Quote:> pid = fork();
> if(pid == 0)
> {
> signal(SIGINT,abc);
> sleep(2);
> if (flag)
> printf("signal is received by child\n");
> }
> if (pid > 0 )
> {
> sleep(1);
> kill(pid,SIGINT);
> sleep(5);
> printf("parent exiting\n");
> }
> return 0;
> }
> void abc()
void abc(int sig)
Quote:> {
> flag = 1;
> }
--
Kasper Dupont -- der bruger for meget tid p? usenet.