[Development] Evolving Qt's multithreading API

[Michael Seydl]

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" <joseph.w.crowell at gmail.com>
wrote:

> On 2/27/2013 2:12 AM, BRM wrote:
> >> From: Thiago Macieira <thiago.macieira at intel.com>
> >> To: development at qt-project.org
> >> 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
> > Development at qt-project.org
> > 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130227/6c19d8e9/attachment.html>