ioslave terminating mechanism

aleXXX alexander.neundorf at gmx.net
Thu Apr 18 21:44:27 BST 2002


On Thursday 18 April 2002 11:47, Malte Starostik wrote:
> Am Thursday 18 April 2002 01:52 schrieb Waldo Bastian:
> > On Wednesday 17 April 2002 04:53 pm, aleXXX wrote:
> > > On Thursday 18 April 2002 01:08, Waldo Bastian wrote:
> > > > That's nice and all but it fails to take into account that signal
> > > > delivery is asynchronous and the current code can deadlock when the
> > > > siganl happens to arrive at an inconvenient time. E.g. within a
> > > > malloc or free call. When you then call the destructor your process
> > > > will deadlock.
> > > >
> > > > You simply can't call arbitrary code (the destructor of a slave) at
> > > > any arbitrary moment (when the signal arrives) and expect it to work.
> > >
> > > Ok, so how about setting a flag in the signal handler which is checked
> > > in dispatchLoop() and if it is set call the dtor from there ?
> >
> > That sounds like a much better approach, although you will have to think
> > of ways to make a slave exit which happens to be stuck on a DNS lookup or
> > something.
>
> So maybe the handler sets a flag and calls alarm(5), so the flag is checked
> right after the select() in the main loop, and on SIGALRM the slave
> terminates so it had 5 seconds to shutdown cleanly?

Exactly my thoughts :-)
But, after thinking a bit more about it, e.g. if the ioslave is in a lengthy 
get(), we won't get back to dispatchLoop() soon, so in these cases the 
SIGALARM would hit. Maybe then we should try to execute the dtor by directly 
calling it and setting a second alarm, which will then finally really exit ?
(can a process actually commit suicide, like  kill(getpid(),SIGKILL); ? )

Bye
Alex




More information about the kde-core-devel mailing list