Extra callbacks and pointer fixing

[septag]

I've been thinking about couple of improvements for Cr :

1. Crash callback: when initializing plugins we could pass an optional crash handler callback to report plugin crashes to the host app

2. We could have a reload plugin callback that notifies the host whether a plugin is reloaded, so host can do some extra stuff like pointer fixing (see below)

3. There is a problem where we have to assign some callbacks that reside in the plugin to the host. for example gameplay events or coroutines , etc.. when plugin reloads, the callbacks may become invalid. So we can define another CR_STATE (for example CR_POINTER) like variable section that instead of reloading the section data, it keeps the data, but reports them to the host app, so the host could fix and replace those pointers. in order to not break the api compatibility, we can add a new cr_plugin_load function with these callbacks as arguments.

4. There is also a need for event dispatching to plugins that is somewhat custom and cannot be handled by cr_main. For example you want to post mouse movements to all the plugins. so besides cr_main we could also have cr_events with a void* argument, that we can call a function like cr_dispatch_event from the host app to be called on every plugin. it's also optional. the plugin can also choose to implement it or not

If you are interested I can make a PR for them. Any suggestions ?

[Neopallium]

1. The host can already detect crashes. If the return value from cr_plugin_update() is less then 0, check the failure field. Any value other then CR_NONE or CR_USER is a crash.
2. I also would like more callbacks on the host side. Right now only the plugin gets load/unload events. One work around is to pass a callback to plugin and have the plugin notify the host of load/unload events.
3. Can you give an example of a callback that you would like to fixup?
4. Right now only the cr_main symbol is loaded from the plugin, it might be useful to allow the host to get symbol handles cr_plugin_get_symbol(&ctx, "function_name"). The host can use the handle to call a custom function in the plugin. The handles would be updated on reload/rollback. Calling a plugin function through the handle would need to be protected for crash recover.

[septag]

1. yes you are right. This was actually very context specific, where I wanted to get notified from another module if the plugin is crashed, and not form the main host.

2. yes it would be useful

3. one of my own cases are co-routines , where I pass co-routine callback to the host. when the plugin is reloaded the callback pointer may be changed (this can be extended to other functions like timer callbacks, etc..) . So instead of restoring the callback pointers in the plugin, we actually need to send the new ones to the host app, so the host could replace them in it's internal state.
   I have done this in my fork successfully, by defining CR_POINTER section additional to CR_STATE, so CR_POINTER types are assumed to be pointer obviously and never get restored, instead their new pointers are passed to host application when plugin reloads. Btw, the linux build also had this issue Bug: Elf relocation  #32

4. Yes. it's also implemented in my fork, with something similar to the method you described except it's not generic like cr_plugin_get_symbol. I guess if we implement reload callbacks, this issue can be generalized more easily.

[Neopallium]

@septag See issue #39 I have started working on an API for custom plugin callbacks with support for reloading and crash recovery. The basic support is working see https://github.com/Neopallium/cr/tree/symbols

3. Did you upload your code for CR_POINTER? I haven't been able to find it. I am curious how you manage the pointers on reload.

[fungos]

Closing due inactivity, thank you.