Re^2: Class::Std::Fast cache and threads

Thanks for your reply

I don't actually want anything from Class::Std::Fast in my child threads. The children are only using thread-safe classes. I'm trying to use Class::Std::Fast in the main thread, and then later do something completely unrelated in child threads.

I understand that I could create a thread especially for Class::Std::Fast, using require instead of use,

my $s = STR->new;
$s->one;
$s->two;
$s->three;
[download]

becomes

threads->create( sub { 
    require STR; 
    STR->import; 
    my $s = STR->new;
    $s->one;
    $s->two;
    $s->three;
} )->join;
[download]

This would get STR out of my main thread and into it's own private child thread, but this hardly seems like an elegant or maintainable solution. I'm going to want to import STR at least twice in my code, and create a new thread just for this each time.

As for rewriting CPAN modules to meet my requirements, yes, using moose would be ideal, but I am lazy, and I'll comment out the croak in Class::Std::Fast first. I see no good reason why it should be there.

Is there really no way to :

trick caller()
load a module in only the main thread

Comment on Re^2: Class::Std::Fast cache and threads Select or Download Code

Replies are listed 'Best First'.
Re^3: Class::Std::Fast cache and threads by BrowserUk (Patriarch) on Oct 12, 2010 at 10:44 UTC
load a module in only the main thread Use require in your main thread after you've started all your other threads.	[reply]
Re^4: Class::Std::Fast cache and threads by Boldra (Curate) on Oct 12, 2010 at 11:22 UTC
Thanks for the answer, but I dislike this due to the program flow it will force me into. It will look something like this: load most libraries create threads and put them to sleep load the soap libraries do some soap calls do some other things wake and use the threads, (passing arguments via a share I created earlier?) do some more soap calls Which I don't trust to be very maintainable.	[reply]
Re^5: Class::Std::Fast cache and threads by BrowserUk (Patriarch) on Oct 12, 2010 at 11:53 UTC
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. RIP an inspiration; A true Folk's Guy	[reply]