The question is what exactly do you mean with canceling. I was already in the same place needing a thread to stop in a controlled fashion, but issuing ie a real phtread_cancel is tricky as the kernel may not support thread canceling and stack unwinding in C++ combined with it leads to quite weird side effects ;-)
Why not just using a stop and join mechanism? Worked for me quite well. Mike On Feb 27, 2013 2:13 AM, "Joseph Crowell" <[email protected]> wrote: > On 2/27/2013 2:12 AM, BRM wrote: > >> From: Thiago Macieira <[email protected]> > >> To: [email protected] > >> Cc: > >> Sent: Tuesday, February 26, 2013 10:46 AM > >> Subject: Re: [Development] Evolving Qt's multithreading API > >> > >> On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote: > >>> Personally, I can easily seem myself replacing my current QThread > usages > >>> with this functionality; but I'd want to be able to receive both > >>> start/finished signals (for logging purposes) and be able to > interact with > >>> the QThread object - so the Trampoline object would need to provide > an > >>> interface by which to access the internal QThread, or be a pass thru > for > >>> signals/slots of the QThread. > >> Why? Why do you need access to the QThread object? Please don't answer > the > >> started / finshed signals -- those will be provided. > > Querying the status of the thread, and waiting for termination - e.g. > QThread::wait(); or connecting a signal to tell it to quit. > > Having a minimal API is great for creating it; but you may still need > access to the other functions provided by the QThread API. > > Either direct access or a pass-thru API would suffice; but it's probably > a lot easier to have: > > > > QThread* Trampoline::getThread() const; > > > > than to do all the signals/slots/etc in the Trampoline object. > > > > $0.02 > > > > Ben > > > > _______________________________________________ > > Development mailing list > > [email protected] > > http://lists.qt-project.org/mailman/listinfo/development > I have threads that live for the full life of my application but telling > them to stop on application shut down is painful. For this reason I > would like to be able to cancel a thread and also have a virtual > function to handle what happens when tread cancel is requested.. i.e. > cleanly closing child objects and handling locked mutexes so I don't get > segfaults. This is possible with current QThread but could be much easier. > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
