Is it safe to use async event handler?

[ultimaweapon]

I was tried to find the implementation of SynchronizationContext in this repository but not found so I'm not sure if it safe to use async on the event handler.

[badcel]

Can you elaborate a bit more on the SychronizatiomContext? (My knowledge on this topic is quite limited.)
What is your use case? Did you experience problems with the current implementation? What do you expect to be available on the current codebase? Can you give a sample?

In General I read through the documentation and can confirm that there is currently no GirCore specific implementation of the SynchronizationContext.

It reads like it is needed to make async/await work without the need to manually dispatch the code back to the main loop to alter UI elements. Can you confirm this?

Additionally we have currently issue #845 which could be related. Do you know if the synchronization context could help to catch those unhandled exceptions to avoid crashing the runtime?

Having some samples would be really great as those could be used to create unit tests to ensure the desired behavior.

[ultimaweapon]

@cameronwhite you are right. @badcel if you are okay with this I can implement both SynchronizationContext and the unit tests in a single PR. If not I'll add only unit tests.

[badcel]

@cameronwhite it looks like it.

@ultimaweapon Nevertheless please don't copy the code but seriously work on this topic. Test things out, make yourself familiar with the scenario, understand what happens and what needs to happen. If you do it like this it is your own work and it has the chance on being better than the one from GtkSharp.

Another question would be where to put the new class into action.

[ultimaweapon]

Maybe inside src/Libs/GLib-2.0/Public because we need to use https://docs.gtk.org/glib/func.idle_add.html? Then we can set it as a default SynchronizationContext inside GLib.Initialize method.

[badcel]

Is there need to have the SynchronizationContext available in the public namespace? GLib.Module.Initialize could call into the GLib.Internal namespace, too. Calling the GLib namespace from GLib.Internal is not a blocker for me.

I would consider it to be needed in the GLib namespace if the user is expected to use the class themself. I never used the synchronization context myself. Is there some usecase to use it directly? If it is just there to "make things work" it could live in the Internal namespace for now.

With version 1.0 there will be some API stability guarantees. If we move the class into GLib namespace it would need to keep it's API otherwise it would be a major version change. I'm not yet sure if the API will be guaranteed to be stable in the Internal namespace or if it is like "use on your own risk" which would allow internal refactorings and optimizations without doing a major version jump.

[ultimaweapon]

Okay I agree to put it in GLib.Internal because it is unusual for people to use SynchronizationContext directly.

[ultimaweapon]

The PR has arrived #856!