error handling when errno == ECHILD ...

R. Kannan kannan at cathedral.cerc.wvu.wvnet.edu
Sun Dec 2 11:12:20 AEST 1990


-- here is the code ....

switch ( ( pid = fork () ) )
    {
      case -1 :
        close ( fdin ) ;
        close ( fdout ) ;
        close ( fderr ) ;
        return ( AMS_OVRLD ) ;
      case 0 :

        execlp("sh","sh","-c",command, (char *) 0 ) ;
        exit ( 127 ) ;

      default:
        istat = signal ( SIGINT, SIG_IGN ) ;
        qstat = signal ( SIGQUIT, SIG_IGN ) ;
        while ( (w=wait(&status)) != pid && w != -1 )
          ;
        signal ( SIGINT, istat ) ;
        signal ( SIGQUIT, qstat ) ;
      }

  /* CLOSE THE OUTPUT FILES */

  close ( fdin) ;
  close (fdout) ;
  close (fderr) ;
  if ( w == -1 ) return (AMS_SVRERR);
  return ( 0 ) ;

-- END of code ....

ERROR SCENARIO

	Running small applications like "ps", 

	wait returns -1 and errno is set to ECHILD.

FROM THE MANUAL

ERRORS

     wait(), wait3(), or wait4() will fail and return immediately
     if one or more of the following are true:

     ECHILD         The   calling   process   has   no   existing
                    unwaited-for child processes.

     EFAULT         statusp  or  rusage  points  to  an   illegal
                    address.

     EINTR          The function was  interrupted  by  a  signal.
                    The  value of the location pointed to by sta-
                    tusp is undefined.


 question#1:

	Is it safe to assume that ECHILD is an harmless error
	and that it is not necessary to propagate the system error 
	any further?
	
by modifying the above code to

	  if ( w == -1 && errno != ECHILD ) return (AMS_SVRERR);

	because:

	ECHILD only implies that the child process does no longer exist.

	ECHILD does not imply that there CHILD quit abnormally.

	That is indicated in status.


request#2:(not a question)

	Could someone share with us piece of code that 
	analyzes the return value in "status" for all 
	possible error conditions.



Thanks

--kannan



More information about the Comp.unix.questions mailing list