SIGSTOP and SIGKILL

[Ravi Murty]

I haven't tried sending a SIGCONT after this state. I see that one thread of
the process has SIGSTOP still on its signal list, the SIGKILL is cleared
because that's what the process was trying to do when it got caught and
stopped instead. Before this happens, SIGCONT seems to be able to bring the
threads back out of stopped state without any problems.

Ravi

On Mon, Mar 14, 2011 at 2:03 AM, Kostik Belousov <kostikbel at gmail.com>wrote:

> On Sun, Mar 13, 2011 at 11:30:00PM -0700, Ravi Murty wrote:
> > I haven't, are there specific improvements in this area of the kernel?
> First, the 8.2, compared to 8.0, changed the mechanism of delivering
> the process-global signal to a thread. Now, the thread to deliver is
> selected at the moment of delivery, instead of the moment of post.
> This was done to close a race where either thread changed signal mask
> after post, or exited after post, causing signal be undefinitely
> delayed or ignored, respectively.
>
> Second, 8.2 less often stops the threads in the sleep state, more often
> trying to move the thread to safer user<->kernel boundary, to take a stop.
> Sleeping thread might indicate the unsafe sleep (from the POV of stopping)
> by using PBDRY flag to msleep.
>
> Both the changes are not directly address the behaviour you described,
> but they are explicitely in the area of your interest.
>
> BTW, it is not clear to me, does the process in the state as you
> described, able to unwind from the stop state using SIGCONT ? I.e.,
> is it 'weird but recoverable' state, or is it 'weird and unrecoverable'
> state ?
> >
> > On Mar 13, 2011, at 10:30 PM, Erich Dollansky <
> erich at alogreentechnologies.com> wrote:
> >
> > > Hi,
> > >
> > > On Monday 14 March 2011 11:41:21 Ravi Murty wrote:
> > >
> > >>
> > >> Any good solutions to this problem?
> > >
> > > did you try your program on 8.2?
> > >
> > > Erich
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hackers-unsubscribe at freebsd.org"
>