Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

[Solved] Distracting SymbolBrowser Behaviour

<< < (4/6) > >>

Miguel Gimenez:
I wrote that code three years ago, but I have forgotten the details.

CallAfter() is executed in call order (it uses the event queue), but it is possible for a second call to execute while the first is still running. Probably a mutex in ClassBrowser::TreeOperation() fixes this, or waiting for a "finished" flag after each call to CallAfter().

sodev:
I don't know the code you are referring to but your description of how CallAfter() works is wrong. CallAfter() does always post to the main thread, so even if the code executed by CallAfter() does use CallAfter() itself, that code won't execute immediately, your described interleaving of calls can't happen.

Pecan:

--- Quote from: Miguel Gimenez on January 22, 2024, 01:02:51 pm ---I wrote that code three years ago, but I have forgotten the details.

CallAfter() is executed in call order (it uses the event queue), but it is possible for a second call to execute while the first is still running. Probably a mutex in ClassBrowser::TreeOperation() fixes this, or waiting for a "finished" flag after each call to CallAfter().

--- End quote ---

Thank you You're suggestion worked.
By placing a semafore.Wait() after the CallAfter()s and  a semaphore.Post() in the CallAfter()'s target function, all the crashes that I could previously create disappeared.

Whew !!, Thanks again. ;D

Miguel Gimenez:
Happy it worked, good job.

@sodev, what I am telling is: if you execute two consecutive CallAfter(foo) in the worker thread, and foo() in the main thread calls p.e. Yield(), directly or indirectly, then the second foo() will start executing before the first has ended. Control will return to the first foo() when the second ends.

sodev:
That makes sense, i didn't take the dangerous Yield() into account.

Navigation

[0] Message Index

[#] Next page

[*] Previous page