|
in reply to Re: Perl threading stability?
in thread Perl threading stability?
Thanks, it was.
I can see now that Perl5's threading isn't ready for main stream. Having to copy everything is just far too much of an overhead. The idea that Perl updates the "copies" of variables whenever a thread updates a variable is far from efficient.
I don't buy Perl not being able to use references for it's data since it's done in real threading applications just fine. It looks to me that Threading in Perl was added just as a "hack job" to make shared data across "fork()"s (I do know a thread not really a fork()).
My idea wants the ability to share data across threads while maintaining somewhat of a speed benefit from multiple children. However, due to the complexity of Perl's own threads, the performance hit seems to negate the benefits of using threading in the first place.
-- philip
We put the 'K' in kwality!
|
Re^3: Perl threading stability?
by BrowserUk (Patriarch) on Jul 25, 2005 at 20:22 UTC
|
I don't buy Perl not being able to use references for it's data ...
You obviously do not appreciate the problems involved.
... since it's done in real threading applications just fine.
What do you call "real threading"? Are you thinking of Kernel threads in C or User threads in say Java?
Each of these forms of threading have their own set of demands and limitations. In addition, chosing to use either language to benefit from that flavour of threading imposes the disadvantages that language imposes upon the rest of your application.
My idea wants the ability to share data across threads while maintaining somewhat of a speed benefit from multiple children.
Please describe your application in some detail. Ithreads can be used to accomadate many uses, but it does require that you understand both their advantages and limitations.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply] |
|
|
When thinking threading, I always viewed it in the eyes of user threading like in Java. Granted java is memory intensive, it still is efficient at the code level.
Please describe your application in some detail. Ithreads can be used to accomadate many uses, but it does require that you understand both their advantages and limitations.
Right now the application is built using forks. Each fork spawns off a DBI connection of it's own and reads in data from a text file based off the system it's currently updating within the database (data to update is gotten remotely by another script).
The restrictions I currently have and trying to fix is data sharing. Right now when I get an error, I dump it to a temp file and then read in the temp file at the end of the processing. This is possibly one of the most efficient ways of doing it due to the size of the load I have I still rather find something a bit more "less problemantic".
Hashes storing data like server hostnames and a hostname changes. I have a DB loaded hash containing all "active" systems. I need the ability to "change" that has in the case of a hostname change.
I'm also wanting to build an XML file containing human entered discription data for each system (right now it uses bunches of little name=val strings--one file per server). 300+ systems, while a single file might be too much, it's definatly too much for threads. Either case, when a hostname, etc, changes on a system, I need that change updated within the XML hash as well for dumping at the end of the script execution.
-- philip
We put the 'K' in kwality!
| [reply] |
|
|
When thinking threading, I always viewed it in the eyes of user threading like in Java.
The main limitation of java-style user threads is that there is no true concurrency. No matter how many cpus or cores the machine has, a Java app will only utilise one of them at a time no matter how many user threads it spawns. Therefore, you can never scale the app by moving it to a multi-cpu system.
That same limitation is what allows Java threads to be very lightweight and efficient. As only one thread is ever truely running at any given moment, many of the consideration for locking required by apps utilising kernel threads simply do not arise.
It's a swings and roundabouts argument. What you gain in one place, you loose in another.
Your 'spec' is still pretty sketchy, but if I'm reading between the lines correctly, I would say that what you want to do is eminently doable with iThreads.
To be sure, I would need further details including the number of systems you are talking to concurrently; the nature of the data you are sharing etc.
Not only does it sound doable, it sounds pretty straight forward.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply] |
|
|
|
|
|
|
|
|
Re^3: Perl threading stability?
by zentara (Archbishop) on Jul 25, 2005 at 20:03 UTC
|
If you want maximum speed use shared memory. See perldoc IPC::SysV
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
|
|
