Significant delay to thread starting after ::start() called...

chopper

I'm seeing a delay of around three seconds when creating new QThread subclasses between calling ::start() and my class' ::run() method being called.

There's no complicated logic or structures in the QThread based class, it's a very simple worker thread and it logs immediately upon ::run() being called by the new thread.

Is there another way to trigger the start of the thread without using the slot?

Thanks

chopper

I started to think that perhaps qDebug() was being buffered somehow, so I put timestamps in to verify:

1558494899.956
1558494904.849

(milliseconds between ::start() being called and my thread's ::run() being triggered)

It's basically 5 seconds of delay, in a release build.

I tried processing events immediately, I tried release the current thread through sleep(0) , no change. Huge delay.

Any suggestions?

jsulm

@chopper Can you show how you create and start the thread?

J.Hilk

Hi,

you don't give us much to work with. Without explaining more and/or showing the content of your run method, I doubt anyone can give you any good hint/tips/solutions.

You are aware, that subclassing QThread is not the recommended way of doing it?

chopper

I realize I didn't put anything about how I actually implemented this; however, that was intentional as I was looking for obvious 'gotchas' that people knew about, for example (just hypothetically) - "Oh, well, creating a QThread is known to do this if the default threadpool is 1 or..." - et cetera.

As for subclassing QThread not being 'recommended' - I assume you're referring to people's proclivity for misusing moveToThread - there's nothing wrong with subclassing QThread itself as far as I know, it's why it has a ::run() method to begin with...

The implementation is really simple.

I have a class that derives from QThread called ThreadedFetch.

ThreadedFetch* pFetcher = new ThreadedFetch();
Q_ASSERT( pFetcher != nullptr );

pFetcher->start();

That's it.

The only thing in the ThreadedFetch::Run is a local QMutex object and a while loop containing a 100 millisecond sleep on each iteration.

Normally it calls another function (which is its purpose) - but I have disabled that for now.

It's very, very simple. This is why I find this behavior odd.

Thx

JonB

@chopper
You still don't show your code, instead you tell us it used to have mutexs, loops, delays and calling other functions, but it doesn't now. Does it call the base run() --- who knows? Does it have its own event loop --- who knows? Please don't take offence, but that's not great for divining where your code has a 5 second delay when patently other peoples' does not.

If it really does "nothing special", would it not seem sensible to give your code a try without any subclassing and just using a plain QThread? Then you could compare against your behaviour.

If you don't think the above is helpful, that's fine, it's just my observations/thoughts.

P.S.
If you're interested, I believe the latest "final word" was in https://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html. That summary was:

Rules of thumbs

When to subclass and when not to?

If you do not really need an event loop in the thread, you should subclass.

If you need an event loop and handle signals and slots within the thread, you may not need to subclass.

mranger90

I think you should take a look at the rest of your code.
A delay of almost exactly 5 seconds tells me that something blocking until it times out.
Somewhere, you are probably waiting on a mutex or a semaphore or event, etc and its blocking
the thread until it times out.