RE: accept
> 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/
RE: accept
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 - 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/
Re: accept
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 - 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/
Re: accept
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 - 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/
RE: accept
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
-
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/
RE: accept
> 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 - 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/
RE: accept
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(); dupetc, 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. - 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/
Re: accept() fails with EINTER
linux-os wrote: Trying to run an old server with a new kernel. A connection fails with "interrupted system call" as soon as a client attempts to connect. A trap in the code to continue works, but subsequent send() and recv() calls fail in the same way. Anybody know how to mask that SIGIO (or whatever signal)? Setting signal(SIGIO, SIG_IGN) doesn't do anything useful. Well, knowing what signal it actually is would help.. tried running it in a debugger? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: accept() fails with EINTER
> Trying to run an old server with a new kernel. A connection > fails with "interrupted system call" as soon as a client > attempts to connect. A trap in the code to continue > works, but subsequent send() and recv() calls fail in > the same way. Weren't you supposed to just 'try again' when receiving EINTR (or EAGAIN)? Folkert van Heusden Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden! +--+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See| |http://vanheusden.com/multitail/features.html for a feature list. | +--= www.unixsoftware.nl =-+ Phone: +31-6-41278122, PGP-key: 1F28D8AE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: accept() fails with EINTER
On Thu, 24 Feb 2005 [EMAIL PROTECTED] wrote: Trying to run an old server with a new kernel. A connection fails with "interrupted system call" as soon as a client attempts to connect. A trap in the code to continue works, but subsequent send() and recv() calls fail in the same way. Weren't you supposed to just 'try again' when receiving EINTR (or EAGAIN)? Absolutely. However it's an old server that used to work with 2.4.22 and before. I don't want to have to rewrite everything and Why should send() recv() read() write(), etc. always get an EINTR everytime something uses them? It doesn't happen on other systems. I think that something is supposed to be masked OFF that isn't being masked OFF Folkert van Heusden Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden! +--+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See| |http://vanheusden.com/multitail/features.html for a feature list. | +--= www.unixsoftware.nl =-+ Phone: +31-6-41278122, PGP-key: 1F28D8AE Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
