I tried to reproduce it on the mandelbrot sample and I had no problems. Then, I've thought immediately where I could have done a mistake previously (even if I didn't keep the tried code) !!!
MyThread *thread = new MyThread();
in the constructor of my class !!! I instanciate a local object to my constructor rather than using the member :
thread = new MyThread();
I was quite tired, sorry !
I haven't seen such a thing in the documentation. You can use asynchronous call only for one way messages so if you don't need an answer.Can't gSOAP make asynchronous calls? Anyway gSOAP call hangs on some system call like read and you can send a signal to cause it to return immediately with EINTR. Then you'll be able to shut down the thread.
You can only deal with time-out but this is not a solution I want for the reactivity of my app.
Moreover, the documentation say :
---
Caution: Many Linux versions do not support non-blocking connect(). Therefore, setting soap.connect_timeout for non-blocking soap_call_ns__method calls may not work under Linux.
---
I will listen to you even if it works now and if I think there could not conducts to problems (but the application does something serious because it deals with customers data).Still, using terminate is dangerous. Of course if your application doesn't do anything serious, consequences will also be minimal.
Now that I have found my mistake regarding on the heap QThread allocation, I could manage myself when the thread should be destroyed.
So if the QThread's theorical parent (I won't give this to the QThread constructor to avoid cascading deletion process of Qt) is to be destroyed, I could now launch a monitoring code in the QApplication object, from the QThread's parent destructor that will destroyed the thread after it has properly terminate his job.
Thanks for your answers and to tell me that it is still very bad to deal with evil ;o)
Bookmarks