|Pathologically Eclectic Rubbish Lister|
.... regardless of BrowserUk's belief that threads, especially Perl threads, will give you some sort of performance boost ..... try it yourself and see, .....huge overheads
....maybe they do in MSWindows....but not under linux...and frankly, i would not use an OS that let a process running on one core of a multi-core system, alter the goings on in a neighboring core..... that is what you seem to be suggesting...... i could start a perl script, start x number of threads, and be assured that each thread (code block) will be assigned to a separate core..... with cross-core variable sharing thru threads::shared? .....bad design......
on linux, each thread of a spawned thread set shares the same pid, and if you call exit from any thread, it takes down all threads under the master thread, including the master thread.... what more evidence do you need that they share the same pid?... and probably have their nice level set as a whole based on the master thread's pid
...so even though in theory, BrowserUk's assertion that Perl threads will give you concurrent processing... in all likelihood, they won't..... i would bet for security, a pid gets spawned into 1 core, and since threads on linux share the same master pid, all threads probably will be assigned to the same core.... otherwise it would be chaos as programs try to spawn threads into other cores..... maybe it is done in sloppy OS's ?..... but not to abandon the intent of my reply..... threads are good if you want easy realtime sharing of data between threads..... but they are not for speed
...what you want to look at is forking and using shared memory segments for the best speed.... read "perldoc perlipc" and look for the section SysV IPC.... it is the fastest
.... and that is no baloney...i'm a vegetarian ;-)
I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku