Closed septag closed 4 years ago
cr_plugin_update()
is less then 0, check the failure
field. Any value other then CR_NONE
or CR_USER
is a crash.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.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 #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.
@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
CR_POINTER
? I haven't been able to find it. I am curious how you manage the pointers on reload.Closing due inactivity, thank you.
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 exampleCR_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 newcr_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 besidescr_main
we could also havecr_events
with avoid*
argument, that we can call a function likecr_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 notIf you are interested I can make a PR for them. Any suggestions ?