http://qs321.pair.com?node_id=124953


in reply to Re: Re: Re: Re: Re:(wog) Win32::Gui + Threading?
in thread Win32::Gui + Threading?

Your problem is probably derived from trying to use the GUI from two threads. Don't do that. In your case what is probably happening is that when the forked process trys to pop-up its message box, the Win32::GUI event loop isn't running (since it just exited) so nothing happens.

I advise against using Win32::GUI from multiple threads because Win32::GUI stores it's data in shared (not-thread-specific) variables (at the C level), so race conditions could easily cause crashes if you do not restrain from using it in only one thread.

update: I have neglected to give an explanation as to why perl sticks around. I cannot think of a reason for it to not terminate after 20 seconds, unless Win32::GUI::MessageBox blocks, which would explain it.

  • Comment on Re: Re: Re: Re: Re: Re:(wog) Win32::Gui + Threading?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re:(wog) Win32::Gui + Threading?
by Flame (Deacon) on Nov 13, 2001 at 04:53 UTC
    It still behaves the same with this code:
    pipe(FROM_P, TO_C) or die "pipe: $!"; select(((select(TO_C), $| = 1))[0]); if (!(my $pid = fork)){ close(TO_C); my $running = 1; while(my $line = <FROM_P>) { #Win32::GUI::MessageBox(0,"Child Pid $$ just read this: $line"," +GMS Alert"); chomp($line) if($line =~ m/\n$/o); if(lc($line) eq 'exit'){ exit; } } }


    So I don't think it's caused by the messagebox.


    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.12
    GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
    PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
    ------END GEEK CODE BLOCK------
    Translate

    "Weird things happen, get used to it."

    Flame ~ Lead Programmer: GMS

      I think prehaps your behavior is caused by buffering of the input, then. Is the problem fixed when you close TO_P (after sending the exit command) or when you send exit\n instead of exit? (Which may be enough to convince perl that it should return from the <FROM_P> which I think it's not doing. But it'd be nice if you'd to have the forked process to print some stuff (to a file or STDERR) so you can tell where its hanging...)
        Oh... yep, that did it...

        Could I use something similar to that first pipe() command to get data back from the 2'nd process?

        Something like:
        pipe(FROM_C, TO_P) or die "pipe: $!"; select(((select(TO_P), $| = 1))[0]);


        ???


        -----BEGIN GEEK CODE BLOCK-----
        Version: 3.12
        GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
        PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
        ------END GEEK CODE BLOCK------
        Translate

        "Weird things happen, get used to it."

        Flame ~ Lead Programmer: GMS