Re: [perl-win32-gui-users] Fork?

[Glenn L. <Gle...@ne...>]

Tom Allebrandi wrote:

> The problem here I think is that what we are commonly referring to as a
> "thread", isn't. It must be viewed as if it is a separate process.

Well, from Windows point of view, it is a thread.  From Perl's point of view, it
is a process.  The Perl interpreter is busily keeping the data separate between
the two threads (I'm not sure I understand the complete technique of the magic
that does that, but I'm sure it can be made to work because the Perl language
doesn't expose "real" addresses (much)).

On the other hand, the (Unix) model for "fork" is that the multiple processes
(threads on Perl for Windows) start off with identical data/variables/file
handles.  And the Windows model for "windows" is that the windows are owned by a
process (not a thread), and can be accessed by any thread that has the window
handle.  (And in fact, because Windows was developed on DOS, the windows are
even a bit visible to other processes, but that doesn't concern us here.)   So,
I earlier alluded to some experimentation I was going to try... read on.

> If you create an object in one "thread" (process), it does not exist in the
> other "thread" (process). I can't see any way to use the object syntax on an
> object that was not created in my "thread" (process). Maybe I missed
> something along the way.

By creating the Win32::GUI objects before forking, both the parent and child
threads get copies (?) of the object variables.  Because of the nature of
Windows, the embedded Window handles inside both copies of the object variables
are equally usable.  Because of the (present) nature of Win32::GUI, whereby most
of the parameter data is pumped into Win32 API parameters, and most of the
return values are obtained by calling Win32 APIs to obtain it, I have shown
experimentally that it is possible to use the Win32::GUI object references from
both a parent and a child thread.

Now it is important to remember that Windows only delivers window messages to
the first thread of a program, so in the Perl "fork" environment, this gets
translated to only the parent process of a group of Perl-forked processes can
successfully run Win32::GUI::Dialog (Yep, I tried it the other way first,
figuring that the parent could more easily monitor the child process for death,
since fork returns the child pid, and waitpid works that way--but it just hung,
and the windows never appeared).

However, the child can use the object references created by Win32::GUI to access
the "IsEnabled", "IsVisible" attributes of the window widgets, and they are
dynamically updated (not cached in the object).  The child can access the
current selection from combo boxes.  The child can enable and disable widgets,
and the display gets updated appropriately.

This is quite adequate for my application, which now can do its "long"
operations in the child "process", and keep the GUI window "active" (except that
certain parts get disabled during "long" operations).

Thanks again, Tom, for broadening my outlook regarding Win32::GUI.  Perhaps I've
now returned the favor?

--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
                       -- Will Rogers