with that initial thread repawning itself ad infinitum?
On Windows, none. On *nix, from previous threads it appears that the implementations leaks a few k for each new thread.
But unless the OP is intending that the buttons on this Tk gui be used as those on a gmaes controller in a first person shoot'em up, even the *nix leak is unlikely to be a big problem.
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.
| [reply] |
Well the OP said he was running some heavy code from the threads. So that probably means he's going to be importing some modules, like CGI, DBD, PDL?, whatever.....and that code will now be incorporated into the next spawned thread, in the copy-on-create process. This is going to cause problems in subsequent generations.... as it's parent was contaminated by previous code.Your interesting solution, would require spawning 1 primordial virgin thread, which is used for nothing more than to spawn more clean threads.
Because that virgin copy, cannot import any modules, without polluting it's own next copy, it can only have a breeder function.
Having that breeder thread laying there, just to spawn more, is quite wasteful.
On linux, there comes a time to fork. I advocate forking from the threads, so that the threads only get created once, and act as controllers for the forked code they run.
This is the big difference between threads on Windows and Linux. On linux, there is a distinction between forking and threads, whearas on Windows fork() is emulated.
On linux, forking code has many advantages over threads, the memory cleanups are better, and probably faster, and thread safety of modules becomes a non-issue.
| [reply] |
