It will make it easier to keep an overview of your variables, but a separate package won't influence the memory issues I mentioned earlier. If you don't care about memory and speed, that's fine.
If you do care, read on.
When you use global variables, they are created in the package scope, and copied for each created thread. If you use my inside your threaded function, the memory for that variable will only be allocated as needed, and only after spawning a new thread.
That being said, I do think your program isn't very clear about what which variable is global and which is not, and it would benefit the readability (and ease of debug) to declare each and every variable, either with my (lexical, sometimes called "local" in other languages) or with our (global), and use strict; to enforce that.
You also might take a look at Threads::Queue, which could be a replacement for your @queue variable. | [reply]
[d/l]
[select] |
You're asking the wrong person. You asked in response to a post that boils down to "What issue with globals and threads?"
Don't get me wrong. Global variables should be avoided. The solution is to properly scope your variables with my, not to make every function a module. That doesn't even make variable less global (although it does lessen the chance of a name collision).
| [reply]
[d/l] |