error in system call

error in system call

[Earl R. Lapus]

Mohammed Khalid Ansari wrote:

Hi,

I have seen many source code and almost all code conatain something like
this , if the system call fails, then print the error message and quit (eg
fork error, malloc error etc.)

####

if ((pid = fork()) < 0)
{
	perror ("fork error");
	exit (1);
}
####

That means, if the kernel can not fork or malloc the memory then the 
program will simply quit. Can it be not dangerous. Suppose this sort of 
programs in real time working fine as daemons but after some days, it 
happens that the kernel is not able to allocate the memory or fork, the 
program will simply quit. Is it not dangerous?

Instead can we not write the code in a better way like the following....

while ( (pid = fork()) < 0 );

in this case it will keep on trying to fork till it succeeds. Is that a 
true piece of code?

regards...
======================================================

::I think:: there is a limit to the number 
of child processes for each process.
if this limit is reached then the fork() call
would return an error. Therefore the code:

while ( (pid = fork()) < 0 );

would result to an infinite loop if 
such limit is reached.

>>I COULD BE WRONG WITH THIS<<

=========================
 ...what i want and what i need
 IS and WILL always be FREE...
=========================

Re: error in system call

[Billy O'Connor]

   while ( (pid = fork()) < 0 );

   would result to an infinite loop if 
   such limit is reached.

   >>I COULD BE WRONG WITH THIS<<

No, I believe you're correct.  I'd at least do:

   while ( (pid = fork()) < 0 )
   	 sleep(n);

--
Billy O'Connor

Re: error in system call

[Glynn Clements]

Earl R. Lapus wrote:

> I have seen many source code and almost all code conatain something like
> this , if the system call fails, then print the error message and quit (eg
> fork error, malloc error etc.)
> 
> ####
> 
> if ((pid = fork()) < 0)
> {
> 	perror ("fork error");
> 	exit (1);
> }
> ####
> 
> That means, if the kernel can not fork or malloc the memory then the 
> program will simply quit. Can it be not dangerous. Suppose this sort of 
> programs in real time working fine as daemons but after some days, it 
> happens that the kernel is not able to allocate the memory or fork, the 
> program will simply quit. Is it not dangerous?

If the process is unable to obtain a necessary resource, e.g. memory,
it may not be able to do anything other than quit.

> Instead can we not write the code in a better way like the following....
> 
> while ( (pid = fork()) < 0 );
> 
> in this case it will keep on trying to fork till it succeeds. Is that a 
> true piece of code?

How do you know that the fork() will eventually succeed?

Maybe the process table is full with processes which are waiting for a
response from your daemon. Or maybe it's full with processes which you
daemon has previously spawned, and which, even after they terminate,
won't go away until their parent wait()s for them; which won't happen
if the parent is stuck in a loop trying to fork() another process.

More generally, this situation is known as deadlock. Two (or more)
processes are stalled, each waiting for a resource which is held by
the other. The situation will only be resolved if one of the processes
gives up, and releases the resource which it holds without having
obtained the resource which it desired.

In general, if a system call fails due to insufficient resources, the
application should probably respond by releasing some resources, i.e. 
by terminating.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: error in system call

[Mohammed Khalid Ansari]

On Fri, 14 Jun 2002, Glynn Clements wrote:

> 
> Earl R. Lapus wrote:
> 
> > I have seen many source code and almost all code conatain something like
> > this , if the system call fails, then print the error message and quit (eg
> > fork error, malloc error etc.)
> > 
> > ####
> > 
> > if ((pid = fork()) < 0)
> > {
> > 	perror ("fork error");
> > 	exit (1);
> > }
> > ####
> > 
> > That means, if the kernel can not fork or malloc the memory then the 
> > program will simply quit. Can it be not dangerous. Suppose this sort of 
> > programs in real time working fine as daemons but after some days, it 
> > happens that the kernel is not able to allocate the memory or fork, the 
> > program will simply quit. Is it not dangerous?
> 
> If the process is unable to obtain a necessary resource, e.g. memory,
> it may not be able to do anything other than quit.
> 
> > Instead can we not write the code in a better way like the following....
> > 
> > while ( (pid = fork()) < 0 );
> > 
> > in this case it will keep on trying to fork till it succeeds. Is that a 
> > true piece of code?
> 
> How do you know that the fork() will eventually succeed?
> 
> Maybe the process table is full with processes which are waiting for a
> response from your daemon. Or maybe it's full with processes which you
> daemon has previously spawned, and which, even after they terminate,
> won't go away until their parent wait()s for them; which won't happen
> if the parent is stuck in a loop trying to fork() another process.

While waiting in the while loop to fork(), it migth happen that the kernel
releases its process entries belonging to SOME OTHER processes from the
process table and then while loop return with successful fork(); 

Is that not right?

> 
> More generally, this situation is known as deadlock. Two (or more)
> processes are stalled, each waiting for a resource which is held by
> the other. The situation will only be resolved if one of the processes
> gives up, and releases the resource which it holds without having
> obtained the resource which it desired.
> 
> In general, if a system call fails due to insufficient resources, the
> application should probably respond by releasing some resources, i.e. 
> by terminating.
> 
> 

Re: error in system call

[Glynn Clements]

Mohammed Khalid Ansari wrote:

> > > I have seen many source code and almost all code conatain something like
> > > this , if the system call fails, then print the error message and quit (eg
> > > fork error, malloc error etc.)
> > > 
> > > ####
> > > 
> > > if ((pid = fork()) < 0)
> > > {
> > > 	perror ("fork error");
> > > 	exit (1);
> > > }
> > > ####
> > > 
> > > That means, if the kernel can not fork or malloc the memory then the 
> > > program will simply quit. Can it be not dangerous. Suppose this sort of 
> > > programs in real time working fine as daemons but after some days, it 
> > > happens that the kernel is not able to allocate the memory or fork, the 
> > > program will simply quit. Is it not dangerous?
> > 
> > If the process is unable to obtain a necessary resource, e.g. memory,
> > it may not be able to do anything other than quit.
> > 
> > > Instead can we not write the code in a better way like the following....
> > > 
> > > while ( (pid = fork()) < 0 );
> > > 
> > > in this case it will keep on trying to fork till it succeeds. Is that a 
> > > true piece of code?
> > 
> > How do you know that the fork() will eventually succeed?
> > 
> > Maybe the process table is full with processes which are waiting for a
> > response from your daemon. Or maybe it's full with processes which you
> > daemon has previously spawned, and which, even after they terminate,
> > won't go away until their parent wait()s for them; which won't happen
> > if the parent is stuck in a loop trying to fork() another process.
> 
> While waiting in the while loop to fork(), it migth happen that the kernel
> releases its process entries belonging to SOME OTHER processes from the
> process table and then while loop return with successful fork(); 

Sure. But:

1. If process table entries are sufficiently scarce that the fork()
failed the first time, should this particular program get the next
available entry? Or should it quit, allowing its resources to be used
by something more important?

2. There are other reasons why fork() might fail. E.g. the process
itself has caused RLIMIT_NPROC to be exceeded; in which case, fork()
will continue to fail until some child processes die and the parent
reaps them (which will only happen if it calls wait() etc).

There are two main issues in determining how to handle a failed system
call.

1. Whether the problem is transient, i.e. whether subsequent attempts
are more likely to succeed. It isn't usually possible to determine
this accurately, and any guess will be wrong at least some of the
time.

2. If the call involves allocation of some limited resource (and many
calls may require memory allocation), should the program release
resources, or keep trying to obtain more?

In the case of fork(), if the problem is related to memory
availability, you almost certainly *shouldn't* continue trying to
fork(). The fork() may well succeed once there's just enough memory to
complete the fork() but, if the VM system overcommits (as is currently
the case for linux) the child process will probably fail as soon as it
starts trying to modify memory; and you can't catch that.

More generally, if a resource allocation request fails, the program
should normally just give up. If it tries to continue, often it will
just keep encountering resource allocation failures, effectively
grinding to a halt. All of this time, it will be tying up resources
without any benefit.

Programs which need to continue running in spite of resource
starvation really need to be designed to have constant resource
requirements, and allocate all necessary resources at startup.

-- 
Glynn Clements <glynn.clements@virgin.net>

RE: error in system call

[Singh, Umesh K (MED)]

simply depends upon the requirement.
-us

-----Original Message-----
From: Mohammed Khalid Ansari [mailto:khalid@ncst.ernet.in]
Sent: Friday, June 14, 2002 10:37 AM
To: linux c programming mailing list
Subject: error in system call



Hi,

I have seen many source code and almost all code conatain something like
this , if the system call fails, then print the error message and quit (eg
fork error, malloc error etc.)

####

if ((pid = fork()) < 0)
{
	perror ("fork error");
	exit (1);
}
####

That means, if the kernel can not fork or malloc the memory then the 
program will simply quit. Can it be not dangerous. Suppose this sort of 
programs in real time working fine as daemons but after some days, it 
happens that the kernel is not able to allocate the memory or fork, the 
program will simply quit. Is it not dangerous?

Instead can we not write the code in a better way like the following....

while ( (pid = fork()) < 0 );

in this case it will keep on trying to fork till it succeeds. Is that a 
true piece of code?

regards...

-- 

**************************************************************************

Mohammed Khalid Ansari                    Tel (res) : 0091-022-3051360
Assistant Manager II                          (off) : 0091-022-2024641
National Centre for Software Technology   Fax       : 0091-022-2049573 
8th flr,Air India Build. Nariman Point,   E-Mail    : khalid@ncst.ernet.in

Mumbai 400021.

Homepage : http://soochak.ncst.ernet.in/~khalid			  	  

**************************************************************************

-
To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

error in system call

[Mohammed Khalid Ansari]

Hi,

I have seen many source code and almost all code conatain something like
this , if the system call fails, then print the error message and quit (eg
fork error, malloc error etc.)

####

if ((pid = fork()) < 0)
{
	perror ("fork error");
	exit (1);
}
####

That means, if the kernel can not fork or malloc the memory then the 
program will simply quit. Can it be not dangerous. Suppose this sort of 
programs in real time working fine as daemons but after some days, it 
happens that the kernel is not able to allocate the memory or fork, the 
program will simply quit. Is it not dangerous?

Instead can we not write the code in a better way like the following....

while ( (pid = fork()) < 0 );

in this case it will keep on trying to fork till it succeeds. Is that a 
true piece of code?

regards...

-- 

**************************************************************************

Mohammed Khalid Ansari                    Tel (res) : 0091-022-3051360
Assistant Manager II                          (off) : 0091-022-2024641
National Centre for Software Technology   Fax       : 0091-022-2049573 
8th flr,Air India Build. Nariman Point,   E-Mail    : khalid@ncst.ernet.in 	
Mumbai 400021.

Homepage : http://soochak.ncst.ernet.in/~khalid			  	  

**************************************************************************