[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: plugin system
From:       Bavo De Ridder <bavodr () poboxes ! com>
Date:       1999-08-31 16:31:21
[Download RAW message or body]

On Tue, 31 Aug 1999, Matthias Elter wrote:

>Use the portable ltdl code (see kdecore) to dlopen the plugin libs. The libs

Thanks for the hint of ltdl, I needed that for my KTL. I am currently working
on a more dynamic version in which different threading implementations can be
loaded at program startup.

>are dlopened two times by the plugin manager: On startup to resolve a symbol 
>"PluginInfo* getPluginInfo()" used to collect plugin info for the database and
>on plugin invokation.  Plugin invokation "void run()" is wrapped into "void
>init(PluginInterface*)"  and "void cleanup()" calls on dlopen/dlclose to hand
>the PluginInterface over and to make sure the plugins have a chance to clean up
>used resources. The plugins run in seperate threads using Bavo de Ridder's KTL.
>The plugin manager simply queries a system wide and a local plugin dir and
>decides based on the file date wether it has to update the plugin database.
>
>+ portable
>+ fast
>+ I have working code for this approach.
>+ We can optionally grant direct access to canvas data structures to avoid data
>transfers.
>+ Plugin writers are not scared away by KOM.
>- A shared lib fooling around with canvas data can easily crash KIS.

It this happens than the access interface was not well written. A good
interface should make it impossible for a plugin to crash the application.
However, the plugin runs in the same address-space as kimageshop, so a division
by zero in the plugin will also bring down kimageshop (or a segfault, ....).


BDR

[prev in list] [next in list] [prev in thread] [next in thread]