A Process for Each Plugin

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

A Process for Each Plugin

Developers mailing list
Hi,
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.
- 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.
- 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?
Regards.
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: A Process for Each Plugin

Simon Budig
Hi Ahmad.

Ahmad Nouralizadeh via gimp-developer-list ([hidden email]) 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
--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: A Process for Each Plugin

Developers mailing list
Thanks, Simon. It is really thorough and helpful.

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

> Hi Ahmad.
>
> Ahmad Nouralizadeh via gimp-developer-list ([hidden email])
> 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
> --
>               [hidden email]              http://simon.budig.de/
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list