On Sun, Oct 22, 2017 at 2:26 AM, Thiago Macieira
wrote:
> It's implemented for all classes. The harness is not part of QtTest: it's
> the
> set of tools that run the applications.
>
I didn't mean to imply the contrary. Sorry, in hindsight it's obvious I
phrased my writing pretty badly. I meant t
On Saturday, 21 October 2017 11:25:43 PDT Konstantin Shegunov wrote:
> The Qt Continuous Integration system has a timeout of 15 minutes for any
>
> > test,
> > except tst_QNetworkReply (that one is allowed to run for longer). That
> > way, we
> > don't depend on any internal state being consistent
On Sat, Oct 21, 2017 at 8:16 PM, Thiago Macieira
wrote:
>
> In this case, I'd just have the test harness kill the processes that
> deadlocked and report the failure.
>
Alright, I'll take it under advisement.
The Qt Continuous Integration system has a timeout of 15 minutes for any
> test,
> excep
On Saturday, 21 October 2017 10:01:26 PDT Konstantin Shegunov wrote:
> Assuming my test is failing, which would be the whole reason of writing
> tests to check the implementation, right, I would likely end up a situation
> where a sibling process waiting for a message from the root process, while
>
On Sat, Oct 21, 2017 at 7:51 PM, Thiago Macieira
wrote:
>
> Yes, if someone writes the code. I'm not volunteering.
>
Fair enough, I'll see if I can squeeze it in the future then.
> What do you mean by that? .acquire() does return (if that's what you mean
> by
> "free the thread") if there was s
On Saturday, 21 October 2017 09:42:45 PDT Konstantin Shegunov wrote:
> On Sat, Oct 21, 2017 at 7:35 PM, Thiago Macieira
> wrote:
> > The reason is that it was never implemented. I've just checked and both
> > backends could have it.
>
> This is encouraging. Could we maybe have that implemented/ad
On Sat, Oct 21, 2017 at 7:35 PM, Thiago Macieira
wrote:
>
> The reason is that it was never implemented. I've just checked and both
> backends could have it.
>
This is encouraging. Could we maybe have that implemented/added to the
class for a future release?
> As to what you're stuck with, we n
On Saturday, 21 October 2017 09:29:49 PDT Konstantin Shegunov wrote:
> Hello,
> Is there any technical reason why QSystemSemaphore doesn't provide a
> `tryLock` method (as the regular one does)? Am I stuck to starting a
> separate thread to "emulate" such a behavior manually or is there a better
>
Hello,
Is there any technical reason why QSystemSemaphore doesn't provide a
`tryLock` method (as the regular one does)? Am I stuck to starting a
separate thread to "emulate" such a behavior manually or is there a better
way of achieving it?
Thanks in advance!
__
