Re: [Gimp-developer] A Process for Each Plugin

Thanks, Simon. It is really thorough and helpful.

On Tue, 7 May 2019 at 13:16, Simon Budig <[email protected]> wrote:

> Hi Ahmad.
>
> Ahmad Nouralizadeh via gimp-developer-list ([email protected])
> wrote:
> > I wonder why GIMP spawns a separate process for each plugin (e.g., by
> > calling g_spawn_async() @app/plug-in/gimpplugin.c:368). For example, I
> > opened an image and the contents of the image was loaded in the memory of
> > process gimp. But when I applied a VanGogh filter on the image, a new
> > process, van-gogh-lic, started and processed the image contents.
>
> Yes, this is completely as designed and expected.
>
> > - Why another process is forked? AFAIK, a fork is used only for the cases
> > when the tasks of the parent and child are completely different.
>
> Having the tasks in different processes has a few advantages:
>
>  * plugins can be small completely separate entities with a very
>    specific small scope. This makes them easy to understand and fast to
>    develop
>  * buggy plugins don't case the main gimp process to crash and burn
>  * they work independently of the actual GIMP version.
>
> An alternative would be to create plugins as shared libraries that get
> linked into the main application. This might have some complications
> with the build process as well as the intricacies of the dynamic
> linking. But it would be doable.
>
> > - How does van-gogh-lic access the contents of the image, while it is
> > loaded in its parent (i.e., the gimp process)?
> > - I also traced the parent process using Pin, which showed that during
> the
> > application of the filter, many accesses were made by gimp. Why?
>
> Plugins use libgimp, which takes up the task of communication with the
> main application. There is quite some back and forth between these two
> processes using an IPC mechanism. A plugin that invokes a PDB function
> basically asks GIMP to do the task.
>
> The actual image data is transferred via shared memory: The two
> processes work on the same pixel data, which avoids expensive copying of
> data.
>
> In the future more image operations will become GEGL-Ops, This is indeed
> a step into "dynamic linking" area, but hopefully the GEGL
> infrastructure is good enough to make it reasonably easy to wrap the
> head around.
>
> I hope this helps,
>          Simon
> --
>               [email protected]              http://simon.budig.de/
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [email protected]
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
_______________________________________________
gimp-developer-list mailing list
List address:    [email protected]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list