There are several plugins that share limited resources, such as scintilla markers and indicators.
At the moment there is no coordination for using those resources so plugins can interfere with one another and possibly with Geany.
The only common thing between plugins and Geany is Geany, so this is a proposal to add a resources management interface to Geany.
The proposed interface is below, I have tried to make it so it is easy to expand to resources that are not integers (markers and indicators are all integers)
enum resource_type { GEANY_RESOURCE_MARKER, GEANY_RESOURCE_INDICATOR }; gboolean alloc_int_resource( enum resource_type, int* resource_num ); void free_int_resource( int resource_num );
This allows extra resources to be added without ABI changes (so long as they are added to the end of the enum).
If (when) other types of resource need managing then extra functions can be added again without breaking the ABI.
Automatic release is not suggested because that prevents use of RAII and similar management schemes in C++ or GC for other plugin languages. For plain C plugins just call free_int_resource in the plugin_cleanup function.
Any simpler, more flexible suggestions?
Cheers Lex
Update:
Matthew has pointed out on IRC that the markers and indicators are per scintilla object, not global. He has a suggested alternative API which he will post after its tested.
Cheers Lex
On 5 April 2013 13:09, Lex Trotman elextr@gmail.com wrote:
There are several plugins that share limited resources, such as scintilla markers and indicators.
At the moment there is no coordination for using those resources so plugins can interfere with one another and possibly with Geany.
The only common thing between plugins and Geany is Geany, so this is a proposal to add a resources management interface to Geany.
The proposed interface is below, I have tried to make it so it is easy to expand to resources that are not integers (markers and indicators are all integers)
enum resource_type { GEANY_RESOURCE_MARKER, GEANY_RESOURCE_INDICATOR }; gboolean alloc_int_resource( enum resource_type, int* resource_num ); void free_int_resource( int resource_num );
This allows extra resources to be added without ABI changes (so long as they are added to the end of the enum).
If (when) other types of resource need managing then extra functions can be added again without breaking the ABI.
Automatic release is not suggested because that prevents use of RAII and similar management schemes in C++ or GC for other plugin languages. For plain C plugins just call free_int_resource in the plugin_cleanup function.
Any simpler, more flexible suggestions?
Cheers Lex
On Fri, 5 Apr 2013 20:20:55 +1100 Lex Trotman elextr@gmail.com wrote:
Matthew has pointed out on IRC that the markers and indicators are per scintilla object, not global. He has a suggested alternative API which he will post after its tested.
On Tue, 9 Apr 2013 23:20:16 +0100 WILLIAM FRASER william.fraser@virgin.net wrote:
What do people think about these options? Does anyone have any other ideas?
This was discussed before. At that time Lex was agains global resource mapping and wanted per-sci resource allocation instead. I will only repeat my suggestions:
1. Check how many resources we are using. If they are below the global limit or slighly above it, per-sci makes no sense.
2. If they are above the limit, check how much per-sci will improve the things. If it's less than, say, 15%, per-sci makes no sense.
3. If per-sci still seems reasonable, provide some logical to physical mapping, so that the plugins woudn't need to remember each allocated resource separately for each sci.
On 11 April 2013 02:25, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 5 Apr 2013 20:20:55 +1100 Lex Trotman elextr@gmail.com wrote:
Matthew has pointed out on IRC that the markers and indicators are per scintilla object, not global. He has a suggested alternative API which
he
will post after its tested.
On Tue, 9 Apr 2013 23:20:16 +0100 WILLIAM FRASER william.fraser@virgin.net wrote:
What do people think about these options? Does anyone have any other
ideas?
This was discussed before. At that time Lex was agains global resource mapping and wanted per-sci resource allocation instead. I will only repeat my suggestions:
- Check how many resources we are using. If they are below the global
limit or slighly above it, per-sci makes no sense.
It makes sense when the resource is only available per sci.
There is no "global" set of markers, just that Geany always set up the same set for its own use in each sci.
Even if a plugin uses the same markers in each sci, regardless of language or other settings, it still has to set them up and release them on each sci. It is more likely though that a plugin will only use markers on a few sci.
So the plugin will have to be allocating the resource per sci anyway, and it will need to track it, yes.
- If they are above the limit, check how much per-sci will improve
the things. If it's less than, say, 15%, per-sci makes no sense.
- If per-sci still seems reasonable, provide some logical to physical
mapping, so that the plugins woudn't need to remember each allocated resource separately for each sci.
Unless they are set and forget uses, the plugin still has to remember them to be able to use them.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 10/04/2013 22:49, Lex Trotman wrote:
It makes sense when the resource is only available per sci.
There is no "global" set of markers, just that Geany always set up the same set for its own use in each sci.
Even if a plugin uses the same markers in each sci, regardless of language or other settings, it still has to set them up and release them on each sci. It is more likely though that a plugin will only use markers on a few sci.
So the plugin will have to be allocating the resource per sci anyway, and it will need to track it, yes.
This is the way I have done it in numberedbookmarks. I use the g_object_set_data() and g_object_get_data() functions passing G_OBJECT(sci) as the first argument, thus attaching a pointer to a structure that can be used to keep track of resource use on a per sci object basis. Other than having to watch out for memory leaks of the structures when shutting down, I think that this is best option to track resource use. What's more, I'm no GTK expert and have not tried it, but but using g_object_set_data_full() would probably be an easy way to prevent memory leaks.
- If they are above the limit, check how much per-sci will improve
the things. If it's less than, say, 15%, per-sci makes no sense.
- If per-sci still seems reasonable, provide some logical to physical
mapping, so that the plugins woudn't need to remember each allocated resource separately for each sci.
Unless they are set and forget uses, the plugin still has to remember them to be able to use them.
If a you're going to create a structure holding handles to the resources used on a per sci object basis to ensure no clashes in resource use anyway, then it would be a simple matter to write a function returning the handle of a numbered resource. A plugin would not then have to remember which ones were allocated, but could simple call the function with the resource number and sci object, with the knowlage that if null were returned then the resource was not in use.
However I feel that this slightly goes against the ethos of geany and geany-plugins being as light-weight as possible by adding another function to the geany-plugins api that is not essential. A plugin writer would have insight into if a plugin needed to keep track of resource use or not (geany-plugins would be keeping track of which resources were in use or not anyway, so there is no need to replicate this if a plugin didn't need to remember this information once a resource had been established), and it would be a relatively simple matter of adding a simple way of keeping track of which resources a plugin uses. On the other hand, having such a simple function would keep plugins simpler, and thus less likely to contain any bugs.
William
On Thu, 11 Apr 2013 07:49:41 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
On Thu, 11 Apr 2013 12:56:22 +0100 William Fraser william.fraser@virgin.net wrote:
[...]
Let me confirm. You haven't checked the total resource usage, because you expect that a plugin will allocate a resource the first time it needs it, and release the resource as soon as it doesn't need it any more (as opposed to, say, reserving a resource based on the file type). Thus it's reasonable to expect that per-sci allocation will considerably the improve resource usage. Am I correct?..
--
For the record:
marker usage: scintilla: 25..31, folding geany highlighting: 0 (goto line), 1 (bookmark) debugger: 12..17 numbered bookmarks: dynamic #s, 10 markers scope: 17..19, configurable
maximum marker usage: 25 / 22 (debugger / scope) geany/scintilla: 9 available to plugins: 23 used by plugins: 16 / 13 (70% or 55%) fully available: 7 / 10 fastest resolution: numberedbookmarks -> 2..11, scope -> 12..14
[debugger and scope will never be used together]
indicators: scintilla: none (0..2 defined) geany: 0 (GEANY_INDICATOR_ERROR), 8 (GEANY_INDICATOR_SEARCH) spellcheck: uses GEANY_INDICATOR_ERROR
Either I'm missing something big, or we'll never out of these.
Other resource types: havent't checked.
On 13 April 2013 03:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 11 Apr 2013 07:49:41 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
On Thu, 11 Apr 2013 12:56:22 +0100 William Fraser william.fraser@virgin.net wrote:
[...]
Let me confirm. You haven't checked the total resource usage, because you expect that a plugin will allocate a resource the first time it needs it, and release the resource as soon as it doesn't need it any more (as opposed to, say, reserving a resource based on the file type). Thus it's reasonable to expect that per-sci allocation will considerably the improve resource usage. Am I correct?..
--
For the record:
marker usage: scintilla: 25..31, folding geany highlighting: 0 (goto line), 1 (bookmark) debugger: 12..17 numbered bookmarks: dynamic #s, 10 markers scope: 17..19, configurable
maximum marker usage: 25 / 22 (debugger / scope) geany/scintilla: 9 available to plugins: 23 used by plugins: 16 / 13 (70% or 55%) fully available: 7 / 10 fastest resolution: numberedbookmarks -> 2..11, scope -> 12..14
[debugger and scope will never be used together]
indicators: scintilla: none (0..2 defined) geany: 0 (GEANY_INDICATOR_ERROR), 8 (GEANY_INDICATOR_SEARCH) spellcheck: uses GEANY_INDICATOR_ERROR
Either I'm missing something big, or we'll never out of these.
Nothing wrong with your math, but the suggestion was started by talking to someone who is writing *another* plugin that wants to use markers, and the next one etc.
Certainly we can be authoritative and assign a range to the current plugins that are in G-P, but thats not all plugins, and how do we manage it? If someone comes and says "for new_plugin I need 10 markers", we havn't got them if bookmarks and debugger are allowed for. So we would have to say to users, sorry, you can't run new_plugin and debugger together, or you can't run new_plugin and bookmarks together, and who is going to decide which combinations are allowed? And anyway which user is going to RTFM where we say what combinations are legal? So fixed allocations is not the answer.
Cheers Lex
Other resource types: havent't checked.
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sat, 13 Apr 2013 09:46:53 +1000 Lex Trotman elextr@gmail.com wrote:
On 13 April 2013 03:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Let me confirm. [...] you expect that a plugin will allocate a resource the first time it needs it, and release the resource as soon as it doesn't need it any more (as opposed to, say, reserving a resource based on the file type). Thus it's reasonable to expect that per-sci allocation will considerably the improve resource usage. Am I correct?..
For the record: [max usage 16/23 markers, 0/28? indicators]
Nothing wrong with your math, but the suggestion was started by talking to someone who is writing *another* plugin that wants to use markers, and the next one etc.
The math was for the record only; I really wanted to know if we expect the resource management described above. It looks nice, and certainly matches numberedbookmarks, but is not convinient for scope (and probably debugger).
Certainly we can be authoritative and assign a range to the current plugins that are in G-P, but thats not all plugins, and how do we manage it?
I suggested that as a fastest resolution only. Resource management may be required in the future, but the ability to allocate markers globally will be helpful. Or at least some resource ID manager, otherwise each plugin has to attach it's own key/data pairs for each sci, like William did.