On Tue, 31 Aug 1999, Bavo De Ridder wrote:
> On Tue, 31 Aug 1999, Matthias Elter wrote:
> >On Tue, 31 Aug 1999, Bavo De Ridder wrote:
> >> On Tue, 31 Aug 1999, Matthias Elter wrote:
> >> >- 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, ....).
> >
> >Yes thats the problem, but on the other hand:
> >- The "official" KIS package will include only stable plugins tested by us.
> >- A user probably wont blame _us_  for alpha quality plugin x he found
> >on page y crashing his KIS.
> 
> I know that LinuxThreads is implemented using the clone() call -> something
> like fork + shared memory. Perhaps in this system and with some signal-handlers
> one could run a plugin in a seperate thread AND make only the thread crash in
> case of problems.

This might work, I'm going to look into this. I favour  the shared libs
approach and (in)stability was the main argument against it, so if
we can get this sorted out...

Shared libs are not easy to debug but as we need a plugin writing howto no
matter what plugin system we implement we can simply add a step by step guide on
how to debug shared libs.

Greetings, Matthias

P.S.: Bavo, you are the threading expert, can you play around with your thread
libs and investigate what exactly happens to a sample app when a thread
crashes?

--
Matthias Elter
me@kde.org / me@main-echo.net
KDE developer