From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land
Date: 3 Nov 2000 13:27:03 -0800 [thread overview]
Message-ID: <8tvaj7$mql$1@cesium.transmeta.com> (raw)
In-Reply-To: <200011031841.MAA07209@isunix.it.ilstu.edu> <3A031591.EA24ABFA@moberg.com>
Followup to: <3A031591.EA24ABFA@moberg.com>
By author: george@moberg.com
In newsgroup: linux.dev.kernel
>
> Thanks for the info.
>
> After looking at it, let me modify my position a bit.
>
> My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
> failing because, deep inside glibc somewhere, nanosleep() is returning
> EINTR.
>
> My code is not using signals. The threading library is, and there is
> obviously some subtle bug going on here. Ever wonder why when browsing
> with Netscape and you click on a link and it says "Interrupted system
> call."? This is it. I'm arguing that the default behaviour should be
> SA_RESTART, and if some programmer is so studly that they actually know
> what the hell they are doing by disabling SA_RESTART, then they can do
> it explicitly.
>
They do so explicitly by not specifying SA_RESTART. It's a bitmask,
and the behaviour of each bit is specified by POSIX.
> I don't mean this to sound like a rant.
It does... it sounds like a rant someone who hasn't even bothered
looking up the relevant standards and interfaced.
> It's just that I can't possibly ascertain why someone in their right
> mind would want any behaviour different than SA_RESTART.
Synchronous post-processing of signals. Too many things cannot be
safely done in a signal handler context.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-03 21:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200011031841.MAA07209@isunix.it.ilstu.edu>
2000-11-03 19:44 ` Can EINTR be handled the way BSD handles it? -- a plea from a user-land george
2000-11-03 21:27 ` H. Peter Anvin [this message]
2000-11-04 4:23 ` Theodore Y. Ts'o
2000-11-06 14:05 ` George Talbot
2000-11-06 15:30 ` Davide Libenzi
2000-11-06 17:50 ` Can EINTR be handled the way BSD handles it? -- a plea from a Tim Hockin
2000-11-06 14:17 ` Can EINTR be handled the way BSD handles it? -- a plea from a user-land George Talbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='8tvaj7$mql$1@cesium.transmeta.com' \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.