`use Prima` creates an extra process?

[mohawk2]

This was prompted by a strange circumstance: in perldl, if I have PDL::Graphics::Prima (and obviously deps) installed, then run demo, it will list the demos including prima. If I then exit the shell, it will throw errors about Prima failing to load, then still be in the shell and list all the demos except prima.

I can strip this down to:

• running perldl
• in another shell listing the processes on that terminal (shows bash and one perl)
• in the perldl running require Prima
• in the other shell doing ps now shows two perls

Output:

Loaded PDL v2.085_02 (supports bad values)
Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
pdl> p $$
801744
pdl> require Prima
pdl> q
Ctrl-C detected
Compilation failed in require
pdl> p $$
801745
pdl> q

This is on Linux. Note that while it reports a Ctrl-C, I didn't do one there (perldl uses either Sys::SigAction or installs a $SIG{INT}). Why is Prima creating an extra process? Why is it having that error?

[dk]

Under unix/gtk Prima indeed creates a forked process because of the idiotic wayland policy to not allow screenscraping to processes that did not register in dbus under a specific application name. But since Prima has its own application name, the only way to do so is in a forked process.

I have never experienced problems with terminating Prima programs, with ctrl c or otherwise, and it doesnt intercept sigint or other signals, unless of course gtk does it.

To disable this, Prima apps respond to the --no-gtk command line switch, but since perldl is not a prima app, it wouldn't help there...probably recompile without gtk and see if that helps?

Anyway i'm not sure what to be done here because while unusual, theres nothing wrong in forking a process, of course if it behaves properly. But that forked process is fairly primitive and i dont see how it could interfere here. I would suspect perldl's signal handling

/dk

I'm not sure

[dk]

Still cannot reproduce...

Loaded PDL v2.081 (supports bad values)

Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)

pdl> p $$
1782340
pdl> require Prima

pdl> p $$
1782340
pdl> q
$

[mohawk2]

Do you have Sys::SigAction installed?

[dk]

No, but after having it installed I confirm the ctrl c error. However I still cannot see two different pids before and after demo.

That require error at line 26 pointing at the use Prima clause which is strange...

Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
pdl> p $$
1897353
pdl> demo
Use:
   demo pdl         # general demo
   demo bad         # Bad-value demo (Optional: PGPLOT)
   demo cartography # Cartographic projections (Req.: PGPLOT)
   demo prima       # Prima graphics
pdl> p $$
1897353
pdl> q
Use:
   demo pdl         # general demo
   demo bad         # Bad-value demo (Optional: PGPLOT)
   demo cartography # Cartographic projections (Req.: PGPLOT)
Ctrl-C detected
Compilation failed in require at /usr/local/share/perl/5.34.0/PDL/Graphics/Prima.pm line 26.
BEGIN failed--compilation aborted at /usr/local/share/perl/5.34.0/PDL/Graphics/Prima.pm line 26.
Compilation failed in require at /usr/local/share/perl/5.34.0/PDL/Demos/Prima.pm line 5.
BEGIN failed--compilation aborted at /usr/local/share/perl/5.34.0/PDL/Demos/Prima.pm line 5.
Compilation failed in require
pdl> q
$

[dk]

update: seems to be a false alarm or something - I reinstalled PDL::G::P from the latest github checkout, and after that everything is fine again. So no error from here...

[mohawk2]

Thank you for the further investigation. I was looking again in perldl, do you have Term::ReadLine::Gnu installed?

[dk]

yes, I also have that module

[mohawk2]

When Prima forks, can you make it close at least stdin? That would probably sort this out.

[dk]

Hmm might be something actually... can you try this patch that does it?

diff --git a/unix/gtk.c b/unix/gtk.c
index 62eda7b8..688ee9d9 100644
--- a/unix/gtk.c
+++ b/unix/gtk.c
@@ -290,6 +290,8 @@ prima_gtk_init(void)
        if ( socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, gtk_screenshot_sockets) == 0) {
                gtk_screenshot_pid  = fork();
                if ( gtk_screenshot_pid == 0 ) {
+                       close(STDIN_FILENO);
+                       close(STDOUT_FILENO);
                        close(gtk_screenshot_sockets[0]);
                        run_screenshot_app();
                        exit(0);

[mohawk2]

With your patch, after I run demo prima, I get pages of syntax errors, as though some parsing got stopped halfway through then resumed with a file pointer in the wrong place. When I remove the patch and reinstall Prima (from your git master), it's back to about 8 layers of error after the demo finishes.

Why does Prima always do this fork on startup? I've never felt a need to take a screenshot of a Prima app. Why is your framework the only one that's having this problem?

[dk]

The thing is that while it may look stupid to not fork on-demand, it doesnt work that way with gtk. Gtk with its startup talks to dbus and says "i am such and such application and i can use such and such api". Enters wayland. Wayland screenscraping is royally fucked up - a regular application cannot do that when it wants to. However there are screenscraper applications that work under wayland, and they do so by specifically registering as a "screen grabber" with a hard coded name to dbus. One cannot change that name after gtk init. That's why the fork, and that's why during the startup.

Another thing is that I simply cannot reproduce your error. Could you possibly make a virtualbox vm that i can download an play with it? That waywe can check out of the fork call is the cause of the problem.

You also try to comment the forking code and see if that helps? However if it is, we wouldn't know how to make it work with pdl anyway...

So my best advice is to make it to try to make it a reproduceable case