Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-06 Thread Thiago Macieira
Em terça-feira, 6 de setembro de 2016, às 16:08:59 PDT, Viktor Engelmann escreveu: > It is just a (more extreme) example of my point: > > If the user bypasses our security measures and shoots himself in the > foot - why should we take any responsibility for that? The problem here is that you

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-06 Thread Viktor Engelmann
It is just a (more extreme) example of my point: If the user bypasses our security measures and shoots himself in the foot - why should we take any responsibility for that? Am 06.09.2016 um 01:44 schrieb Thiago Macieira: > Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Thiago Macieira
Em segunda-feira, 5 de setembro de 2016, às 18:46:04 PDT, Alexander Nassian escreveu: > Please don’t get me wrong, but that would imply that if enough people (for > whatever reason) expect eg. QSettings to be compatible with WinAPI calls > that should be changed. If I’m not wrong QThread doesn’t

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Thiago Macieira
Em segunda-feira, 5 de setembro de 2016, às 18:46:41 PDT, Giuseppe D'Angelo escreveu: > Il 05/09/2016 17:04, Alexander Nassian ha scritto: > > 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 > >

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Thiago Macieira
Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann escreveu: > So what if the user adds an asm statement that changes a register and > doesn't declare that register to be changed? That would also cause his > "Qt" application to misbehave... or what if he links the object

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Marc Mutz
On Saturday 03 September 2016 09:03:21 Thiago Macieira wrote: > > Can't swallow doesn't mean can't catch. You can catch it, but you can't > > not rethrow. But if you call std::terminate(), the rethrow will never be > > reached. > > But that doesn't do what we want. We want to rethrow the

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Alexander Nassian
> Am 05.09.2016 um 18:38 schrieb 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

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Giuseppe D'Angelo
Il 05/09/2016 17:04, Alexander Nassian ha scritto: > 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? Maybe one is just using a 3rd party library that assumes pthreads, not

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread 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

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread 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

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-05 Thread Viktor Engelmann
So what if the user adds an asm statement that changes a register and doesn't declare that register to be changed? That would also cause his "Qt" application to misbehave... or what if he links the object files to a custom loader that doesn't call the constructors for global objects? We can lock

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-03 Thread Thiago Macieira
Em sexta-feira, 2 de setembro de 2016, às 23:45:26 CEST, Marc Mutz escreveu: > On Friday 02 September 2016 22:35:59 Thiago Macieira wrote: > > However, the documentation from the ABI says that forced unwinds cannot be > > stopped, so you can't swallow the exception even if you wanted to. Are you >

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-02 Thread Marc Mutz
On Friday 02 September 2016 22:35:59 Thiago Macieira wrote: > However, the documentation from the ABI says that forced unwinds cannot be > stopped, so you can't swallow the exception even if you wanted to. Are you > sure that the application crashes when you pthread_exit() when >

Re: [Development] Using platform-native APIs for terminating QThreads

2016-09-02 Thread Marc Mutz
On Friday 02 September 2016 12:32:48 Giuseppe D'Angelo wrote: > 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

[Development] Using platform-native APIs for terminating QThreads

2016-09-02 Thread Giuseppe D'Angelo
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