[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    [quanta-devel] deleteLater() and kapp->processEvents
From:       Linus McCabe <Linus () mccabe ! nu>
Date:       2005-09-24 10:04:50
Message-ID: 200509241204.50199.Linus () mccabe ! nu
[Download RAW message or body]


Hi!

In the Gubed plugin, on some places, I have to use "m_socket->deleteLater();" 
instead of "delete m_socket;".

I think this is due to some kind of race condition:

1) Gubed sends a network message to Quantas Gubed plugin.
2) The network socket's read slot is invoked, which in turn calls the Gubed 
plugin's command handler.
3) The command handler calls QuantaApp::slotStatusMsg
4) QuantaApp::slotStatusMsg calls kapp->processEvents
5) Meanwhile, Gubed is done running the script and closes the connection. 
Because of the processEvents (even thought its supposed to 
ExcludeSocketNotifiers) the Gubed plugin's socket recieves a connectionClosed 
event.
6) The socket object is deleted in the connectionClosed slot.
7) Quanta crashes because we're in sub frame stack of an object being deleted.

I _think_ this is why it crashes anyway, and I've used the workaround of using 
deleteLater() instead of just a delete.

This makes it not crash, but instead, it might be that the socket is deleted a 
little too late and keeping the port occupied when a new instance tries to 
bind to the port.

For the DBGp plugin I could completely eliminate all deleteLater()s, because 
there I had separated network and plugin core much better (hey, I've been 
learning stuff from workin on quanta :)

And I guess the permanent solution for the Gubed plugin would be to do the 
same separation, but that's a little much for the current 3.5 code, I 
think...

Anyone have another suggestion or can think of a reason of why this is 
happening?

cheers

/Linus
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel

[prev in list] [next in list] [prev in thread] [next in thread]