From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 06 Nov 2000 10:50:37 -0800
> 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.
Why are you talking such a nonsense?
The claim was made that
From: Ulrich Drepper [EMAIL PROTECTED]
Date: 06 Nov 2000 10:50:37 -0800
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.
Why are you talking such a nonsense?
The claim was made that pthreads
Hello!
> Glibc has to use signals because there *still* is not mechanism in the
> kernel to allow synchronization.
Could you tell why does it use SA_INTERRUPT on its internal signals?
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> "Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> Why are you talking such a nonsense?
[Note to self:
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> 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.
Why are you talking such a nonsense?
>
> However, from a portability point of view, you should *always*
"Theodore Y. Ts'o" [EMAIL PROTECTED] writes:
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.
Why are you talking such a nonsense?
However, from a portability point of view, you should *always* surround
Hello!
Glibc has to use signals because there *still* is not mechanism in the
kernel to allow synchronization.
Could you tell why does it use SA_INTERRUPT on its internal signals?
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
I seem to recall when reading about sigaction in APUE, that while sigaction
solves many of the races that can come up with various "signal"
implementations, there were still some cases where there was no way to do
what was desired without races. Is there ANY way (in theory, at least) to
On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:
> I don't mean this to sound like a rant. It's just that I can't possibly
> ascertain why someone in their right mind would want any behaviour
> different than SA_RESTART.
study apache 1.3's child_main code, you'll see an example of EINTR in use.
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
>
> Hello!
>
> > > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > > what BSD does: re-start the interrupted call?
> >
> > This is crap. Returning EINTR is necessary
On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:
> Considering that the threading library for Linux uses signals to make it
> work, would it be possible to change the Linux kernel to operate the way
> BSD does--instead of returning EINTR, just restart the interrupted
> primitive?
>
It's just how the
Hello!
> > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > what BSD does: re-start the interrupted call?
>
> This is crap. Returning EINTR is necessary for many applications.
Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
Alexey
-
To
Ulrich Drepper wrote:
>
> [EMAIL PROTECTED] writes:
>
> > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > what BSD does: re-start the interrupted call?
>
> This is crap. Returning EINTR is necessary for many applications.
>
> --
> ---.
[EMAIL PROTECTED] writes:
> Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
--
---. ,-. 1325 Chesapeake Terrace
Considering that the threading library for Linux uses signals to make it
work, would it be possible to change the Linux kernel to operate the way
BSD does--instead of returning EINTR, just restart the interrupted
primitive?
For example, if I'm using read(2) to read data from a file descriptor,
Considering that the threading library for Linux uses signals to make it
work, would it be possible to change the Linux kernel to operate the way
BSD does--instead of returning EINTR, just restart the interrupted
primitive?
For example, if I'm using read(2) to read data from a file descriptor,
[EMAIL PROTECTED] writes:
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper wrote:
[EMAIL PROTECTED] writes:
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
--
---.
Hello!
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
Alexey
-
To
On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:
Considering that the threading library for Linux uses signals to make it
work, would it be possible to change the Linux kernel to operate the way
BSD does--instead of returning EINTR, just restart the interrupted
primitive?
It's just how the
Followup to: [EMAIL PROTECTED]
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Hello!
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many
On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:
I don't mean this to sound like a rant. It's just that I can't possibly
ascertain why someone in their right mind would want any behaviour
different than SA_RESTART.
study apache 1.3's child_main code, you'll see an example of EINTR in use.
it's
I seem to recall when reading about sigaction in APUE, that while sigaction
solves many of the races that can come up with various "signal"
implementations, there were still some cases where there was no way to do
what was desired without races. Is there ANY way (in theory, at least) to
23 matches
Mail list logo
