Re: SIGCONT misbehaviour in Linux
Brian Pomerantz (bapper@piratehaven.org)
Fri, 10 Dec 1999 10:17:08 -0800
On Fri, Dec 10, 1999 at 07:29:25AM -0800, Simon Patience wrote:
> In article <82mvls$aqtrr@fido.engr.sgi.com>, you write:
> |> On 8 Dec 1999, Ulrich Drepper wrote:
> |> >This is not what happens on other platforms. At least with my limited
> |> >testing I found that if you do on Solaris
> |> >
> |> > sleep 10
> |> > ^Z
> |> > fg
> |> >
> |> >the process will continue to sleep.
> |>
> |> That's not enough to tell what the kernel is doing, maybe they have a bit
> |> smarter sleep(1) program. `sleep` can be changed to run nanosleep again if
> |> it received -EINTR and `req` is not null. You only have to pass as `req`
> |> the `rem` that you got back from the previous nanosleep call.
>
> No, the problem is that you shouldn't have interrupted it in the first
> place. What is the point of interrupting a blocked process so that you
> can block it?
>
Isn't a process in a blocked state when it is waiting on I/O? I often
will hit ^Z for a long tarball extraction and run it in the
background. When I hit ^Z, the process could be waiting for I/O when
the signal comes through, thus a time when I want to interrupt a
blocked process to block it.
BAPper
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/