What's the size of Qt event queue?

[wysota]

How big is Qt's event queue? Is its size customizable?

Its size is not limited (apart from running out of memory).

Example:

I have 2 threads: thread A and thread B.

A has a signal "Sig()" which is fired at every 1 second.

B has a slot called "Slot()" which takes 2 seconds to process.

I tie the 2 threads together by connecting A "Sig()" to B "Slot()"

Obviously, things will start to queue up. I've verified this that events do get queued up even if Slot() is not keeping up.

This doesn't make much sense unless at some point you are going to stop generating requests.

What's the behavior of the Qt event loop as time approaches infinity. =p

Oh, that's easy to answer - there is no such thing as infinity in computer science

[ShaChris23]

Its size is not limited (apart from running out of memory).

So what happens then when it runs out of memory? How would Qt notify the application programmer? Is there a way for the user to limit the queue size?

This doesn't make much sense unless at some point you are going to stop generating requests.

Yes, that was my intention for writing the example--it was so that I could have Thread1 stop generating requests eventually while Thread2 doing something else.

Speaking of which, is my understanding correct that by using 2 threads, I have 2 independent event threads running? Thus, potentially on multi-core machines, the 2 event loops will be running on different processors?

Oh, that's easy to answer - there is no such thing as infinity in computer science

Well, reason why I said as time goes to infinity is precisely because I want to find out what happens when memory is filled up.

[wysota]

So what happens then when it runs out of memory?

The operating system kills your application to prevent the whole machine becoming unstable.

Is there a way for the user to limit the queue size?

If you limited the queue size, how would the application notify you about that happening if it couldn't post an event to the queue? If your application runs out of memory because of the queue size it means it is unstable because you generate events faster than you can process them, so killing the app is fine (you would probably get an exception and/or a runtime warning).

Yes, that was my intention for writing the example--it was so that I could have Thread1 stop generating requests eventually while Thread2 doing something else.

You can still do that. Or you can give the producer thread a lower priority than the consumer thread.

Speaking of which, is my understanding correct that by using 2 threads, I have 2 independent event threads running?

If you run event loops in both of them then yes. Although they are not really independent (but they can still run in parallel).

Thus, potentially on multi-core machines, the 2 event loops will be running on different processors?

Potentially yes. Of course with regard to the fact that you have more than two threads in your whole system so context switching and cpu affinity will kick in.

Well, reason why I said as time goes to infinity is precisely because I want to find out what happens when memory is filled up.

Kaboom In C++ there is no way of telling whether an allocation will succeed or not. "new" operator never returns null (contrary to malloc). You can only catch an exception if your new operator implementation throws one.