[Development] Using platform-native APIs for terminating QThreads

[Giuseppe D'Angelo]

Il 05/09/2016 16:08, Viktor Engelmann ha scritto:
> We can lock away OUR guns so the user can't shoot himself in the foot
> with them, but if he goes out and buys his own gun, there is nothing we
> can (or should) do about it.

That's not the point. The point is that every time we do an apparently
innocuous change (maybe thinking "surely we never promised POSIX
semantics for our threads!") it turns out that instead there are people
out there that are relying on this behaviour (for whatever reason).

We might have find a couple of workarounds [1][2] for this particular
issue, so in the end the semantics for users are not going to change,
but if the workarounds are not good enough and could not get accepted
then user code is going to break, and that's why I was wondering 1) if
we ever promised something about this issue, and 2) if there's any user
publicly using the feature (I was planning to send an email to interest@
to run a poll about this).



[1] Catch __cxxabiv1::__forced_unwind, as documented here:

> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html

which is what libstdc++'s std::thread also does:

> https://code.woboq.org/gcc/libstdc++-v3/src/c++11/thread.cc.html#execute_native_thread_routine

(but not libc++, wonder why).


[2] Rely on std::current_exception() to return a null std::exception_ptr
in a catch(...) block (!), to represent the fact that there's no
exception but it's a forced stack unwind. Cf. the thread at:

> http://sourcerytools.com/pipermail/cxx-abi-dev/2016-September/002956.html

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160905/50315912/attachment.bin>