[wxperl-users] wxPerl and Perl 5.8 threads

[Marc M. A. <mm...@Do...>]

Just on a lark I decided yesterday I would try to write something using Perl
5.8 and wxPerl.  I compiled everything up on Windows 2000 with VC++ 6 and
everything mostly worked.

I was unable to link the XRC module for some reason.  I suspect some
inconsistency in the build process for wxWindows, but haven't sorted it out
yet.  Don't really care so much about it, just mentioning in passing.

So all (or most) of the sample programs run.  The demo runs except for
whatever I had to comment out because XRC isn't there (I think).  All good.

Then I start to write code.  I copy the minimal frame code and then I start
building other windows to which I attach threads.  My goal is to write a
prime number sieve (see example attached to Perl 5.8 thread tutorial) with
each sieve thread attached to a different window so that the numbers crawl
down a pipeline of windows.  Visually appealing, and my usual test program
for GUI & threads.  So I'm easily amused, so what?

At this point I start finding things aren't quite so good.  The problems
being mostly, I believe, related to the way Perl 5.8 threads are
implemented.  Not to overstate the obvious, but regardless of implementation
detail, they behave more like *NIX forked processes than threads, the
important point being duplication of the data space.

I am able to create the child windows and have them display OK.  After
mulling this over a bit, I find that I'm not surprised.  After all, the
Wx::Window object gets copied to the new ithread and this will include the
Windows handle, which is an integer essentially and therefore copies OK.  So
when I create the new child window and pass it the (copy of the) Wx::Window
parent window object there is a level where Windows API calls are made with
the copied window handle and Windows deals with this OK.

Unfortunately, the child windows never get updated.  The first one does, but
I'm creating that in the main thread.  The rest of the Wx child window
objects are created in child threads that are in separate data spaces.  So
the event handler implemented in the main thread gets an event and can't
resolve it because the event is for a window ID that has no corresponding
window object in the main thread.  I imagine it just gets thrown away.

I tried marking the child window objects as shared but that doesn't work.
If I use the shared attribute I get a crash.  If I use the share() function
after the creation of the window object I get an error message saying I
can't do that, the object won't allow it.

I thought about how the Perl 5.8 threads are set up and it seems like to go
with the flow, as it were, I would have to create a queue for the main
thread and have the main thread process 'commands' from that queue (as
opposed to the Win32 queue events).  I would then have the child threads
send commands to the main threads instead of creating the windows directly.
The main thread sould grab a command and then build a child window based on
that command.  The windows would all get constructed in the main thread.

Of course, I can't do that directly because the main thread is tied up in
the event loop.  Which naturally leads to the idea of posting windows events
that are commands to create windows and so forth.  Which ends up looking
like an event-driven program and not a multi-threaded program.  Why bother,
eh?

So I'm wondering if wxPerl is going to support the Perl 5.8 threading model.
It seems like there's a lot of goop necessary to make that happen.  For
example, there are per-thread static data structures for XS files.  And
there's the whole issue of how to make window objects created in child
threads work with the main thread event loop...or not as the case may be.
And I suspect that these issues will vary considerably between platforms.

Marc M. Adkins