Hmmm....
The trick here is in the doc's it states that ->
my $hash : shared;
-> doesnt share the contents of the has, because hashes aren't really
more than pointers with names. associative arrays that aren't nested
would work, but anythign that containts a pointer needs to have the
variable that the pointer is to also be ': shared'.
There is a trick however for "static" variables. If they are created in
the parent thread before the creation of the child thread, they are
copied data-wise intact to the child thread. Therefor, you can load your
config file and then fire up your worker, and and he will be fine if he
keeps to himself.
Child threads get a copy of *everything* in the parent thread up and
until the time of creation (subs, data, objects, stream pointers (which
are always d.o.a.)...
ps- lock/mutex all *shared* variables (threads::shared, read the docs
and ull get an unerstanding, and I am ass-u-me-ing that you have read
the perl thread tut)
Hope this helps,
Jason Plum
Head of IT R&D
DAJ Strategic Solutions
Steve Loughran wrote:
Hi Jason
All the hash data I would want to use is created once when I load a
config file in (it is not touched at all after this point), so would
passing the hash key via the queue, and having the worker use that key
to process info out of a "static" hash be thread safe?
As its my first venture into Threading, it will be a simple set of code
in the thread, with one way comms ("here is the hash key, go do
something with it, I dont need to know when you are done"). As my
experience grows with threading, and I think of new ways to implement it
in my code, then I`ll start expanding the ways I use it all.
Steve
Jason Plum wrote:
Steve,
From WIK, thread->boss memory spaces are isolated by the perl
interpreter's own threads. (aside from thread::shared modifications)
Generally I do not use a hash to pass back and forth because of its data
structure (pointers out the butt) and difficulty of placing locks on the
data to prevent race conditions and corruption due to one reading while
another is writing. My method of choice is pushing data back and forth
using a queue w/ serialize's freeze/thaw mechanism because you get
accurate data content transfer, without messy pointer errors or the
aforementioned thread competition issues.
I, actually, use a modified version of the ThreadUtils package from back
in the spring when we were all actively playing with the system. I am
not currently gainfully employed as a perl GUI programmer, or I would
have completed my package for others to use. Still, the theoreticals
behind it still stand true. Always lock and/or mutex shared data!!
Somewhere I actually have a working example of a system that
independently operates the different windows outside of the GUI object
space, removing the problematic message stack issues. If I cant find it
and someone needs it, it will take some time for me to whip up, but I
can recreate it in a day.
Jaosn Plum
Head of IT R&D
DAJ Strategic Solutions
Steve Loughran wrote:
Thanks for that, that puts my mind at rest.
Never having written any threaded/forked code before, I need to ask a
few questions:
- Is it safe for a "worker" thread to access hashes/arrays in the "boss"
thread if they only need read access to them?
- Any changes required to "boss" thread hashes/arrays should be handed
back from the "worker" thread through the queue system, and let the
"boss" process and change anything that needs to be changed? Or are boss
hash/array changes done in a worker thread OK? (that sounds like trouble
to be honest).
- Can "worker" threads call subs outside the workers call sub (i.e in
the boss's area)?
Nice examples in the threadutil zip, Robert... clean, simple, to the
point... great as always :)
Steve
[EMAIL PROTECTED] wrote:
Hi,
Yes Win32: :GUI: :ThreadUtils will be integrated into the core - it will not
change that much, perhaps the odd method or function call.
Cheers,
jez
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
