[Development] Using platform-native APIs for terminating QThreads

[Alexander Nassian]

Hi,

Is, or should, that even be supported? I’m just wondering because when I’m using Qt to create a thread, I also use Qt to quit it. Why should anybody use a „foreign“ API?


Beste Grüße / Best regards,
Alexander Nassian

> Am 02.09.2016 um 12:32 schrieb Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>:
> 
> Howdy,
> 
> I'm trying to introduce a change [1] which will make QThread invoke
> std::terminate in case an exception is thrown from the new thread
> (including, but not limited to: user's reimplementation of QThread::run;
> slots listening to the QThread::started / finished signals; custom event
> dispatchers).
> 
> The idea is to align ourselves to what std::thread does.
> 
> There's a small catch, however: user code might be using platform-native
> APIs such as pthread_exit(3) in order to make a QThread quit.
> 
> On some implementations (notably: glibc), pthread_exit is implemented by
> throwing an exception, because it needs to run the pushed cleanup
> handlers. The net result is that, with my change applied, pthread_exit
> won't make the thread exit but crash the application instead (!).
> 
> The question for the ML is: is this a scenario Qt has ever officially
> supported, and a scenario that we should support in the future?
> 
> (QThread documentation does not talk about how QThread itself is
> implemented, so actually relying on the that it has pthread semantics is
> already a slight API abuse by the users).
> 
> [1] https://codereview.qt-project.org/#/c/167240/
> 
> Cheers,
> -- 
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - The Qt Experts
> 
> _______________________________________________
> 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/20160905/6d86ed54/attachment.html>