From: Mike S. <Mik...@Do...> - 2006-10-03 16:50:11
|
We use POE instead -- not threading, but a lot easier for cross-platform work. http://search.cpan.org/~mike/POE-Loop-Wx-0.03/ There are some examples there too. While you can put each frame in its own POE session, our approach now is to have one POE session for Wx, and any other POE sessions as required. Also, we are almost ready to release Wx::Data -- a collection of modules that uses Wx and POE to create data-aware Wx controls that can talk asynchronously back to a POE-based server -- letting the the client use POE and the server. This way a complex frame with multiple controls -- each control can asynchronously connect back to the server (with common cache keys in the client and the server) and populate themselves independently. We are just finishing up a REST-like cachekey / data access that is shared between the controls and the server to allow for distributed caching of data and server-push updates of cache data to the clients. Once that is all done, we'll be doing an initial release to CPAN. Anyhow, all that to say, you may want to consider POE as an alternative to threads. Hope that helps. Mike. Foo JH wrote: > Hello Sergei, > > Thanks for the reply. I don't know if this will work. The abstraction is > so clean I worry if I can control the sharing of variable at all. > > And to answer your question: Perl doc says that threading will duplicate > ALL variables in the main thread. Sounds quite bad to me. > > Does any1 else do threading on wxPerl? > > Sergei Steshenko wrote: > >> --- Foo JH <jhf...@ex...> wrote: >> >> >> >>> Hi all, >>> >>> I'm trying to write an app that does work in the background, and the gui >>> will show any updates based on the background job. >>> >>> The thing is, Perl's threading duplicates all variables. I wonder how in >>> a new thread, I can continue to work on the control objects in the main >>> thread. >>> >>> Any best practice in this area is appreciated. >>> >>> Thanks. >>> >>> |