On Mon, 12 May 2008, Andrew Johnson wrote:
> Michael Abbott wrote:
> > 1. Exiting with epicsThreadExitMain() appears to be a very bad thing, at
> > least on RHEL;
>
> The whole point of the routine epicsThreadExitMain() is to arrange for
> the main thread to complete _without_ shutting down the other threads om
> the process.
Ah, I misunderstood that -- however, it's a red herring in the current
case, as something is going horribly wrong on my machine when we do this.
I need to dig a bit into the pthread specification, but I'm sure I
remember that _exit() is supposed to kill *everything* stone cold dead
without ceremony.
> If you don't ask for an interactive shell there's nothing for the main thread
> to do after loading databases so it calls epicsThreadExitMain(). At this
> point the process looks like a zombie, but it has many other threads still
> running (ls /proc/<pid>/task).
This is very curious.
$ ps ax | grep defunct
31921 ? Zl 0:00 [softIoc] <defunct>
$ cd /proc/31921
$ ls -F
attr/ cwd@ fd/ mem root@ statm wchan
auxv environ loginuid mounts smaps status
cmdline exe@ maps mountstats stat task/
$ ls task
ls: task: No such file or directory
$
Well now. *That's* an interesting surprise.
> If you kill -9 one of these other threads the whole process should shut
> down and the zombie goes away.
Yeah. I think you've broken my machine ;)
What exactly does epicsThreadExitMain() do to try and close the top level
thread without terminating the process? When I've had to do this in my
own processes I've found it easiest to just created a semaphore and block
on it.
> If you want to be able to shut down a softIoc using Control-C, you have to
> start an interactive shell.
Or ... it should always be possible (this is fundamental to Linux) to hunt
down the process and send it a sufficiently aggressive signal (kill -9).
In this case the process has been persuaded into a state where the rules
seem to be broken.
> See above, there are still other threads running in the process.
Perhaps not, at least not where anybody can see them.
> The _exit() call does not trigger the atexit() callbacks which trigger the
> shutting down of the other threads.
Well, it's proving difficult to find a definite statement on this, but
here's the best I've been able to do so far:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/pthread_create.htm
"The thread terminates in the following cases: ... The entire process is
terminated due to a call to ... the ... _exit ... subroutine[s]."
I read that to confirm my understanding that _exit() shouldunconditionally
kill the calling process and all of its threads. Why this isn't happening
on my machine remains a mystery.
- Replies:
- Re: Creating Zombies with epicsThreadExitMain Andrew Johnson
- References:
- Creating Zombies with epicsThreadExitMain Michael Abbott
- Re: Creating Zombies with epicsThreadExitMain Michael Abbott
- Re: Creating Zombies with epicsThreadExitMain Andrew Johnson
- Navigate by Date:
- Prev:
Call to ca_context_destroy results in "Unhandled C++ exception" Simon Rees
- Next:
Queensgate NPS3*** series piezo controller Pedersen, UK (Ulrik)
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Creating Zombies with epicsThreadExitMain Andrew Johnson
- Next:
Re: Creating Zombies with epicsThreadExitMain Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|