A shared thread that processes queued events sounds very complex, that's really what the nthreads config option is for.

It does not explain how to stop the thread when the session is ended. Thus more and more threads will be created.

Seems like an easy fix, just add a on_session_destroyed handler.

It does not explain how to stop the thread when the app is autoreloaded.

Same thing.

Even though there is some attempt at explaining why use of c = threading.Condition() is nescessary I'm not sure the explanation is True.

Yeah, I don't think it's being used correctly, a simple Lock that guards reads and writes of the queue seems sufficient.

I lack some comment about safety of updating Panel components from separate threads. Is that safe? Why?

It's generally safe but of course if you have concurrent manipulation of the same component from multiple threads the standard precautions apply.

Thx. I don't know enough about threads to understand the last too comments. Could you make those more explicit:

Yeah, I don't think it's being used correctly, a simple Lock that guards reads and writes of the queue seems sufficient.

What would that look like in code terms?

It's generally safe but of course if you have concurrent manipulation of the same component from multiple threads the standard precautions apply.

What do you mean by standard precautions? What are they? Where can they be found?

Furthermore the guide only explains how to use manual thread in main app.py file that is not shared between sessions. I would also like to see an explanation of using a single shared thread in external module. As in #6723. I think here concerns about performance comes in. Should this thread be pushing updates to all sessions that .depends on the threads updates? Or should each individual session be running a periodic callback to check for updates? What is most safe and performant?

How would you do this? I don't think nthreads config options would help here.