No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
wake and use the threads, (passing arguments via a share I created earlier?) The 'normal' thing to do is to have your work threads block reading from a que. Your main thread then instigates the worker to do something by posting something to that queue. This obviously doesn't fit with every use case, but without knowledge of your use case it is hard to advise? The problem you describe arises because of the ithreads mechanism of cloning everything currently existing into each newly spawned thread. This is a way of avoiding the problem by avoiding the class(s) giving you problems from being cloned. There are other approaches, some of which were suggested by anonymonk above--like fixing the module. One not mentioned so far is to create a 'thread factory thread'. You start a thread early in the program--before loading most other modules--who's sole purpose is to spawn other threads. Because any threads spawned by the factory thread are clones of it, they will not have anything cloned into them that was not loaded when the factory thread was spawned. The problem with this is that I haven't yet found a way to implement a clean interface for it. If your croak override works, I'd say go for it. But the whole concept of inside-out (flyweight) objects and threads are pretty incompatible. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In reply to Re^5: Class::Std::Fast cache and threads
by BrowserUk
|
|