Thread: Re: [wxperl-users] wxPerl and Perl 5.8 threads

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> 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.
It'd be nice to discover why, how did you compile wxWIndows/wxPerl?
What if you follow the updated build instructions at
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/wxperl/wxPerl/docs/install.txt?rev=1.12&content-type=text/vnd.viewcvs-
markup

> 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.
You should not need to comment anything out, BTW

> 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.
The problem here is that wxWindows expects threads to be worker threads;
they should not create windows; they should communicate with the main thread
via Wx::PostMessage (see the threads sample in the demo).

> 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?
Well, if you have a long computation to run in the background, threads
are a much better solution than a Wx::Timer or idle events...

> 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
I don't think the statics are a big problem; they surely are not causing
the problems you are experiencing. The problem is that (currently) wxWindows
does not support a thread other than the main thread creating windows and
dispatching events.

> 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.
I know Vadim Zeitlin (one of the core wxWindows developers) has a wxGUIThread
(a thread that can create windows and dispatch messages to them) in his TODO
since (at least) 2 years. Of course making it work in at least
wxGTK (variuos UNIX flavours), wxMSW (Win32) and wxMac (OS9 hasn't
preemptive thread, but OSX, AFAIK has), requires a lot of work.

Regards
Mattia

Thread: Re: [wxperl-users] wxPerl and Perl 5.8 threads

Perl wrappers for the wxWidgets C++ toolkit

wxperl-users