Re: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
On Mon, 6 Nov 2000, George Talbot wrote:
> I respectfully disagree that programs which don't surround some of the
> most common system calls with
>
> do
> {
> rv = __some_system_call__(...);
> } while (rv == -1 && errno == EINTR);
welcome to Unix. this is how it is, and it's not just linux. and it's
not just glibc/linuxthreads. in your code do you go about setting all
signals to SA_RESTART? if not then you're subject to the vagaries of
whatever the default signal settings are.
ted mentioned ^Z... there's also strace/truss/ktrace (depending on your
flavour of unix). there's also page-out/in (and on some unixes there's
swap-out/in).
it's something which bites lots of folks. gnu tar had this bug for at
least 5 years, and may still have it -- i got tired of submitting the bug
fix.
-dean
-
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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
Date:Mon, 6 Nov 2000 09:13:25 -0500 (EST)
From: George Talbot <[EMAIL PROTECTED]>
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 && errno == EINTR);
are broken. Especially if those programs don't use signals. The problem
that I'm raising is that the default behavior of returning EINTR from
system calls is, in my opinion, an application reliabilty problem. The
specific problem I'm having is that glibc uses signals to implement
multiple threads, and because of the EINTR behavior, expose multithreaded
programs to this behavior that weren't necessarily written to use
signals.
Arguably though the bug is in glibc, in that if it's using signals
behinds the scenes, it should have passed SA_RESTART to sigaction.
However, from a portability point of view, you should *always* surround
certain system calls with while loops, since even if your program
doesn't use signals, if you run that program on a System-V derived Unix
system, and someone types ^Z at the wrong moment, you can also get an
EINTR. Similarly, you should always check the return value from write
and make sure all of what you asked to be written, was actually
written.
What I normally do is have a full_write routine which looks something
like this:
static errcode_t full_write(int fd, void *buf, int count)
{
char*cp = buf;
int left = count, c;
while (left) {
c = write(fd, cp, left);
if (c < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return errno;
}
left -= c;
cp += c;
}
return 0;
}
It's like checking the return value from malloc(). Not everyone does
it, but even if it's not needed 99% of the time, it's a darned good idea
to do that.
- Ted
-
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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 && errno == EINTR);
are broken. Especially if those programs don't use signals. The problem
that I'm raising is that the default behavior of returning EINTR from
system calls is, in my opinion, an application reliabilty problem. The
specific problem I'm having is that glibc uses signals to implement
multiple threads, and because of the EINTR behavior, expose multithreaded
programs to this behavior that weren't necessarily written to use signals.
It's a useability and portability issue, especially considering that I
might be using pthreads so that I can avoid signal handling entirely. I
might want to do this because I want to be portable to non-UNIX systems
that implement the pthreads API.
I _was_not_ too lazy to read the documentation, though I don't have a copy
of POSIX.
Does POSIX require that pthreads programs be signal-aware in the EINTR
sense? Could this be considered a bug?
--
George T. Talbot
<[EMAIL PROTECTED]>
On Sun, 5 Nov 2000, Marc Lehmann wrote:
> On Fri, Nov 03, 2000 at 02:49:37PM -0500, [EMAIL PROTECTED] wrote:
> > After reading about SA_RESTART, ok. However, couldn't those
> > applications that require it enable this behaviour explicitly?
>
> No, broken applications that require specific bsd behaviour should just be
> compiled with -D_BSD_SOURCE. If you need newer features then be prepared
> to fix the program.
>
> > The problem I'm having right now is with pthread_create() failing
> > because deep somewhere in either the kernel or glibc, nanosleep()
> > returns EINTR during said pthread_create() and pthread_create() fails.
>
> This has hardly something to do with the signal reliability issue, unless
> you compiled your own threads library. You might want to file a bug report
> for libpthread otherwise.
>
> > I don't mean to sound like a psycho on this, but I can't see why
> > SA_RESTART isn't the default behavior. Maybe I'm missing something
> > somewhere.
>
> Yes, you are missing signal(2) or the glibc info file, so the real
> question is: why were you too lazy to read the documentation???
>
>
-
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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 errno == EINTR);
are broken. Especially if those programs don't use signals. The problem
that I'm raising is that the default behavior of returning EINTR from
system calls is, in my opinion, an application reliabilty problem. The
specific problem I'm having is that glibc uses signals to implement
multiple threads, and because of the EINTR behavior, expose multithreaded
programs to this behavior that weren't necessarily written to use signals.
It's a useability and portability issue, especially considering that I
might be using pthreads so that I can avoid signal handling entirely. I
might want to do this because I want to be portable to non-UNIX systems
that implement the pthreads API.
I _was_not_ too lazy to read the documentation, though I don't have a copy
of POSIX.
Does POSIX require that pthreads programs be signal-aware in the EINTR
sense? Could this be considered a bug?
--
George T. Talbot
[EMAIL PROTECTED]
On Sun, 5 Nov 2000, Marc Lehmann wrote:
On Fri, Nov 03, 2000 at 02:49:37PM -0500, [EMAIL PROTECTED] wrote:
After reading about SA_RESTART, ok. However, couldn't those
applications that require it enable this behaviour explicitly?
No, broken applications that require specific bsd behaviour should just be
compiled with -D_BSD_SOURCE. If you need newer features then be prepared
to fix the program.
The problem I'm having right now is with pthread_create() failing
because deep somewhere in either the kernel or glibc, nanosleep()
returns EINTR during said pthread_create() and pthread_create() fails.
This has hardly something to do with the signal reliability issue, unless
you compiled your own threads library. You might want to file a bug report
for libpthread otherwise.
I don't mean to sound like a psycho on this, but I can't see why
SA_RESTART isn't the default behavior. Maybe I'm missing something
somewhere.
Yes, you are missing signal(2) or the glibc info file, so the real
question is: why were you too lazy to read the documentation???
-
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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
Date:Mon, 6 Nov 2000 09:13:25 -0500 (EST)
From: George Talbot [EMAIL PROTECTED]
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 errno == EINTR);
are broken. Especially if those programs don't use signals. The problem
that I'm raising is that the default behavior of returning EINTR from
system calls is, in my opinion, an application reliabilty problem. The
specific problem I'm having is that glibc uses signals to implement
multiple threads, and because of the EINTR behavior, expose multithreaded
programs to this behavior that weren't necessarily written to use
signals.
Arguably though the bug is in glibc, in that if it's using signals
behinds the scenes, it should have passed SA_RESTART to sigaction.
However, from a portability point of view, you should *always* surround
certain system calls with while loops, since even if your program
doesn't use signals, if you run that program on a System-V derived Unix
system, and someone types ^Z at the wrong moment, you can also get an
EINTR. Similarly, you should always check the return value from write
and make sure all of what you asked to be written, was actually
written.
What I normally do is have a full_write routine which looks something
like this:
static errcode_t full_write(int fd, void *buf, int count)
{
char*cp = buf;
int left = count, c;
while (left) {
c = write(fd, cp, left);
if (c 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return errno;
}
left -= c;
cp += c;
}
return 0;
}
It's like checking the return value from malloc(). Not everyone does
it, but even if it's not needed 99% of the time, it's a darned good idea
to do that.
- Ted
-
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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
On Mon, 6 Nov 2000, George Talbot wrote:
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 errno == EINTR);
welcome to Unix. this is how it is, and it's not just linux. and it's
not just glibc/linuxthreads. in your code do you go about setting all
signals to SA_RESTART? if not then you're subject to the vagaries of
whatever the default signal settings are.
ted mentioned ^Z... there's also strace/truss/ktrace (depending on your
flavour of unix). there's also page-out/in (and on some unixes there's
swap-out/in).
it's something which bites lots of folks. gnu tar had this bug for at
least 5 years, and may still have it -- i got tired of submitting the bug
fix.
-dean
-
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/
