However, I've encountered some odd behavior I hope someone can clarify (WinXP, AS 5.8.6). If I attempt to create a new apt. threaded object within an apt. threaded object, and Thread::Apartment's current thread pool is empty, a new thread is spawned via threads->create(\&run, ...args...). But when the new thread starts executing run(), it retains the values of lexically scoped variables declared inside the parent thread's run() instance.
Originally, I had an empty declaration:
Due to the logic of the proxied method dispatch loop, the fact that these variables "acquired" the values of the parent thread caused state issues inside the method dispatch loop.my ($class, $tas, $req, $isa, $methods, $is_io, $is_tas, $tac);
When I changed the declaration to
everything worked fine.my ($class, $tas, $req, $isa, $methods, $is_io, $is_tas, $tac) = (undef, undef, undef, undef, undef, undef, undef, undef);
Is this the intended behavior of threads ? Shouldn't lexically scoped variables be created within the local scope, and take undef as their default value, like any other (non-threaded) recursive call ?
In reply to Threaded recursion and lexical variables by renodino
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |