That makes lots of sense, however when I use perl, very rarely do I encounter problems that require multiple workers working on the same data (and usually I solved such problems with IPC::SharedCache)
Maybe there are some large areas of computing as-of-yet unknown to me, where such problems are common?
| [reply] |
Ok, just because you rarely encounter problems that require multiple workers working on the same data, doesn't mean the rest of us rarely encounter those problems. My main project at work would be greatly helped by threads that worked across Windows, Unix, and Linux. But I don't have them, so I've left it in non-threaded mode.
IPC::SharedCache works great when there's only a little bit of caching. I'm not sure it's great for handling multiple huge trees of objects, from a cursory glance at the CPAN doc.
Any large structure(s) of data where different subsections can be worked on independantly, but the results must be fed back to the main process would benefit from threads. One common area is XML processing - working on each tree in a different worker thread is often possible and even desirable, and then you'll want to amalgamate the results in a final structure so that you can save a new XML file, for example, which cannot easily be done by multiple forked processes due to the close-tags that need to line up properly.
| [reply] |
If I understand you correctly, you're using threads instead of scatter/gather processing?
I don't really see where exactly the gain would be, is the programming simpler, or maybe the setup?
However, I find this statement to be really strange:
Any large structure(s) of data where different subsections can be worked on independantly, but the results must be fed back to the main process would benefit from threads.
This is perfect application for workers pool model, why do you believe threads fit here?
If there would be really large structure, something like gigabytes-worth-of-data, that need to be edited in place, and can be edited by multiple workers, that would be perfect application for threads.
| [reply] |
Yeah, it's very rare, that is why you seldom see threaded code.
In GUI programming, it becomes more common. The case that pops up the most, is displaying a progressbar of some long-running activity, like a download. In a single threaded app, the long-activity may block the gui from updating, and it is very convenient to put the activity in a thread. Of course, we all use tools which are most intuitive to us, so use what works for you. :-)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
| [reply] |