[Qt-interest] Fwd: Fwd: ASSERT failure in QMutex::unlock(): "A mutex must be unlocked in the same thread that locked it."

[Oluwafemi Ade]

---------- Forwarded message ----------
From: Oluwafemi Ade <oamaximpact at gmail.com>
Date: Sat, Jul 17, 2010 at 7:47 AM
Subject: Re: [Qt-interest] Fwd: ASSERT failure in QMutex::unlock(): "A mutex
must be unlocked in the same thread that locked it."
To: Sean Harmer <sean.harmer at maps-technology.com>


This is what I did in QThread's subclass (ClientThread in this case) run()

void ClientThread::run()
{
    QTcpSocket s;   //socket created on the run() stack
    SocketHandler h(qobject_cast<QObject *>(&s), myData);
                           /* h is my worker object */
                          //myData is a QByteArray passed to ClientThread in
its constructor

connect(&s, SIGNAL(connected()), &h, SLOT(sendData()));
connect(&s, SIGNAL(readyRead()), &h, SLOT(readData()));
connect (&s, SIGNAL(disconnected()), this, SLOT(quit()));

s.connectToHost(QHostAddress::LocalHost, 55997);
exec();

}

meanwhile in
void SocketHandler::sendData()
{
    socket.write(myData);
    qDebug() << "the datagram is sent";
}

the write call  was made but the server does not see it, it only sees the
1st connectToHost() call    ( I don't think the fault is from the server
because it responds accurately to another QTcpSocket subclass (not threaded)
I have.


On Sat, Jul 17, 2010 at 5:16 AM, Sean Harmer <
sean.harmer at maps-technology.com> wrote:

> On Saturday 17 July 2010 04:39:45 Oluwafemi Ade wrote:
> > > In summary, it is best to consider QThread purely as a means of
> > > launching another thread, not as the object that does any real work in
> > > that thread (unless you do not need the worker thread to be event
> driven
> > > of course as illustrated in the Mandelbrot example). Much better to
> > > create QObjects within the worker thread to do the work instead.
> > >
> > > HTH,
> > >
> > > Sean
> >
> >    Hi.......clear explanation. I have a similar issue, the QThread lives
> in
> > the main thread, it was created there, so we create a QObject subclass in
> > run and make connections with the QThread subclass and call exec() to
> make
> > the worker event driven.  In my case I want the worker to help send a
> > QByteArray to some server, hence I pass a QByteArray, a QTcpSocket, (a
> > QObject = 0 as its parent in its .h file) to the worker's constructor in
> > run(),
>
> Where do you create the QTcpSocket? The QTcpSocket must have affinity with
> your worker thread for it to work properly. So you should either create it
> in
> your thread's run function or if it has to be created in a different thread
> (e.g. the main thread) then you should call moveToThread() on it to move it
> over to your worker thread.
>
> This means that the QTcpSocket object will then use your worker thread's
> event
> loop.
>
> > which it installs as private variables, also in run() before calling
> > exec I call, connectToHost() on the passed socket, so that part of the
> > connections made is for the workers sendData() function to be called when
> > the socket emits connected(), which actually gets called. But I found out
> > that write() on the socket in the workers sendData() is not seen by the
> > server, though inComingConnection() was seen on the server which
> triggered
> > the worker's sendData() anyways............is there something missing?
>
> If the above does not help you solve it then can you post some code that
> show
> what you are doing please?
>
> Good luck,
>
> Sean
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100717/756cf236/attachment.html