Correct use of Garbage collection

[biddisco]

In the blog/docs it says

To make QSBR work, each thread must periodically call junction::DefaultQSBR.update at a moment when that thread is quiescent – that is, not in the middle of an operation that uses the map. In a game engine, you could call it between iterations of the main loop.

I am experimenting with the leapfrog map, and inserted a call to junction::DefaultQSBR.flush() (since there is no update()). However, when I add the flush call, my code throws exceptions due to empty states in some objects retrieved from the map. There is no single place in the code where I can guarantee that the map is not accessed since everything is completely asynchronous. When one thread is calling flush() another thread might decide to insert or remove something from the map.

Is there a recommended way of dealing with this? (Also please clarify "each thread must periodically call" - do you mean that all threads must call it individually, or can any one single thread call it from time to time).

[preshing]

Hi,

What makes you say there is no update()? It's right here...!

junction::DefaultQSBR.flush() is not the right function to call during normal use. You really need junction::DefaultQSBR.update(). (flush() only exists in case you want to delete all Junction maps and shut down the whole QSBR subsystem, but still keep your app running.)

do you mean that all threads must call it individually, or can any one single thread call it from time to time

Each thread must call update() individually, and each thread must pass its own QSBR::Context to the call. You basically just create one QSBR::Context per thread (if that thread will use a Junction map). You can create the QSBR::Context on the stack.

This inconvenience is admittedly the main drawback to using Junction maps.

[biddisco]

Oops. Sorry, I didn't realize I needed a context per thread and I grepped for update with no arguments and missed it.
I will fix my test and close this issue if I have no further problems. Thanks