[Interest] QTSPCosket signal disconnected()

[Andreas Pakulat]

Hi,

On Tue, Aug 21, 2012 at 10:17 AM, Igor Mironchik <imironchick at gmail.com> wrote:
>> On terça-feira, 21 de agosto de 2012 11.04.14, Igor Mironchik wrote:
>>> I'm playint with this issue. And notice that the problem is not played
>>> too often.
>>> Sometimes slotDisconnected() not invoked in general. What is problem too.
>>> But when he invoked I have stable dead-lock. What is the reason? App is
>>> one-threaded.
>> A deadlock in a one-threaded application usually implies that you tried to
>> lock twice a non-recursive mutex.
>
> I understand it.

I don't think you do understand what Thiago said.

>> Look at your backtrace and figure out what the other lock point was.
>
> But just imagine a situation in which the potential for double locking
> in a one-threaded environment is posiible.
> It is not possible at all. But I see that when executing
> ServerSocket::doThis() sometimes method ServerSocket::slotDisconnected()
> is called asynchronously, so to speak. I.e. in the middle of
> ServerSocket::doThis() invoked ServerSocket::slotDisconnected(). How
> it's possible in one-threaded app?

Well, doThis in your example sends data over the socket, in particular
it flushes the data. This may result in the socket detecting that the
connection was closed from the other side and hence the signal is
emitted. In turn this means the slot connected to the signal is
called.

Since the mutex is locked in doThis and in the slot, but its not a
recursive mutex you're dead-locked. However you don't need a mutex for
a single-threaded app anyway, so just remove it.