-
Is when the
tickevent is fired, in the middle of the event there is a server call or you calltime.sleep(0)or other blocking code, and the control goes back to the event loop. -
Is when the
tickevent is fired, the event does whatever it needs to do, after it ends, the control goes back to the event loop.
I thought you were referring to 3. because you were talking about 5 second intervals.
If you really are talking about 3., where you want to “freeze” something (the form, some data structures, …), while a timer keeps ticking until something happens, then you can’t use a context manager across two executions of the tick event.
If you are talking about 2., then… are you looking for a way to say “I’m going to use blocking code, please don’t execute anything else until I’m done”?
In this case a context manager would make sense, but… there is the risk that if you have a communication problem the app becomes unresponsive. I guess the context manager will have a timeout and eventually abort the transaction and return to normal, so no, there is no problem with that. I like it.
No, since I didn’t understand the request, I thought about how to prevent stuff from happening when you don’t want it to happen. Disabling each single component would be a nightmare as @p.colbert mentioned. I think that it would be easier to focus on what you want to keep enabled.
Basically instead of saying “do not execute any code until I say so” (your request) I was suggesting “do not fire events on any non-whitelisted component” (my self.enable_events_only_in).
Using a context manager is more elegant and water tight, using a whitelist could leak some code execution that is already pending, but could be used across two executions of two tick events.
Sorry, I didn’t want to hijack your request. I thought you were asking for some more advanced ways to create concurrent processes.