ioslave terminating mechanism
Malte Starostik
malte at kde.org
Thu Apr 18 10:44:00 BST 2002
Am Wednesday 17 April 2002 23:39 schrieb aleXXX:
> On Wednesday 17 April 2002 20:41, Waldo Bastian wrote:
> > On Wednesday 17 April 2002 08:11 am, Malte Starostik wrote:
> > > Not sure, but I suspect that this code in slavebase.cpp is rather
> > > dangerous:
> > >
> > > void genericsig_handler(int sigNumber)
> > > {
> > > signal(sigNumber,SIG_IGN);
> > > //I don't think we can have the same problem here as in the sigsegv
> > > handler kdDebug()<<"kioslave : exiting due to signal
> > > "<<sigNumber<<endl; //call the dtor of the slave and exit
> > > if (globalSlave!=0)
> > > globalSlave->~SlaveBase();
> > > exit(2);
> > > };
> >
> > Yes, I think the whole concept of calling a destructor there is
> > misguided. If you need to clean anything up in your io-slave when you get
> > killed you should install a signal handler yourself.
> >
> > Cheers,
> > Waldo
>
> Actually I always expected that the ioslave dtors are called when an
> ioslave exits, until I found out that this is not the case and added the
> dtor calls. Ioslaves feel more like plugins, you think you're writing only
> a lib and a lib shouldn't exit its process (i.e. not handle signals).
> This fixes major problems e.g. with the smbro ioslave.
> I guess other ioslave authors expect the same, why else should they have
> written dtors for their ioslaves ?
Yes, IMHO expecting every ioslave to handle signals itself would cause quite
some confusion and funny behaviour.
> If I understand the code correctly, it changes the behaviour in this way,
> that a signal leads to gen_handler(), which jumps into the if() {} in
> dispatchLoop(), which does the same as the former signal handler did.
> Why does it behave differently ?
So longjmping out of the handler does not put the process is in a saner state
than it is inside the handler?
> Maybe just removing the kdDebug() would already help ?
Probably, in some 50% of the time.
--
Malte Starostik
PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]
More information about the kde-core-devel
mailing list