What does it typically mean when accept returns 0
and that the perror outputs "Interupted system call"??
Thanks
-Mat
--
Mathieu Dube
Mondo-Live
> What does it typically mean when accept returns 0
> and that the perror outputs "Interupted system call"??
Since 'accept' returning zero is not an error, the results of 'perror' are
meaningless. Please read the manual page for 'accept' and notice that it
says, "The call returns -1 on error". Continue reading to understand what a
return value of zero means. Remember that zero is a non-negative integer.
DS
Ok, but fd 0 cant be a valid socket since its the stdin
I posted that on this mailing list coz I thought that this might be a scaling
problem since it happens when theres already several clients connected to the
server
On Sun, 04 Feb 2001, David Schwartz wrote:
> > What does it typically mean when accept returns 0
> > and that the perror outputs "Interupted system call"??
>
> Since 'accept' returning zero is not an error, the results of 'perror' are
> meaningless. Please read the manual page for 'accept' and notice that it
> says, "The call returns -1 on error". Continue reading to understand what a
> return value of zero means. Remember that zero is a non-negative integer.
>
> DS
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
Mathieu Dube
Mondo-Live
On Sat, 03 Feb 2001, you wrote:
> > What does it typically mean when accept returns 0
> > and that the perror outputs "Interupted system call"??
>
> During the call, your process received a signal.
> Most system calls are affected in this way, so that
> you may break out of what you are doing by sending
> a signal to yourself with alarm().
>
> It sucks too, since you have to wrap nearly every
> system call in a while loop. You can avoid some of
> the trouble with careful use of sigaction() to make
> the OS restart system calls in some conditions.
Could it be the SIG32 signal that pthreads use ??
--
Mathieu Dube
Mondo-Live
In article <01020411401700.00110@grndctrl> you wrote:
> Ok, but fd 0 cant be a valid socket since its the stdin
if you have closed stdin (like all daemons usually do) you will get fd 0 on
next open. There is nothing magical about fd0 or fd1.
Greetings
Bernd
On 02.04 Mathieu Dube wrote:
> Ok, but fd 0 cant be a valid socket since its the stdin
>
> I posted that on this mailing list coz I thought that this might be a scaling
> problem since it happens when theres already several clients connected to the
> server
>
It just mean that your stdin was closed some time in the past...
As the prog is a daemon, probably it closed its std{in,out,err} and its
controlling tty.
I do not know if Linux follows the rule that the first fd you get is the
first available. That means that after 'daemonize' you should get the 0
in the first connection. If fd reuse is delayed, you can get the 0 any time
after...
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.2-pre1 #1 SMP Sun Feb 4 13:04:30 CET 2001 i686
> Ok, but fd 0 cant be a valid socket since its the stdin
Wrong. fd 0 can be a valid socket. Read the man page to 'accept' again.
Remember again that zero is a non-negative integer.
> I posted that on this mailing list coz I thought that this might
> be a scaling
> problem since it happens when theres already several clients
> connected to the
> server
If your code called 'perror' in response to getting a zero from 'accept',
your code is broken.
DS
On Sun, 4 Feb 2001, Mathieu Dube wrote:
> Ok, but fd 0 cant be a valid socket since its the stdin
>
Sure it can:
close(0);
close(1);
close(2);
fd = socket(....);
dup....etc, for stdout and stderr.
That said, never, never, ever, check the value of the errno global
unless a function call returned an error. Many/most/all C runtime
procedures don't touch that variable unless an error occurred.
So, reading its value will show the results of something that
happened hours ago (line an interrupted system call).
> I posted that on this mailing list coz I thought that this might be a scaling
> problem since it happens when theres already several clients connected to the
> server
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.