llancet has asked for the wisdom of the Perl Monks concerning the following question:

I've noticed there are so many thread modules.

First of all, we have build-in ithread, although it is ugly: variables are not shared, and are copied on the creation of thread, which consumes memory.

forks is a thread module that implemented on fork, and IPC implemented using socket. It provides API that is very similiar as threads module.

Coro is something different. It is a cooperative model: you have to say cede() frequently to yeild CPU resource to other threads.

omnithreads says it's based on old 5005thread, but it has everything not shared by default. I don't know what's the difference.

Somebody says it's possible to do concurrency things in C using pthread, and do perl things using embedded perl interpreter. I've never tried such ugly method.

At last, we have fork() in most systems.

My question is: all those things above, which ones are both stable and light-weighted?

Replies are listed 'Best First'.
Re: issue of concurrency: which module is better
by Anonymous Monk on Oct 08, 2010 at 06:34 UTC
    My question is: all those things above, which ones are both stable and light-weighted?

    From what I've heard people discuss, none

[reply]
      So, I should use C and pthread, and embedded perl?
[reply]

        llancet:

        As with many questions, "it depends". Without knowing more about the problem(s) you're solving, no-one can give you a good answer. To me, the question sounds something like:

        Hi, I'm considering getting a new vehicle. I've looked at a Ford Explorer, a Mazda Miata, a school bus, a Lotus Esprit, a Honda Prius, and a bicycle. Which one should I use?

        Obviously, that would depend on *your* circumstances. If you were an outdoorsman who frequently camps in the mountains, the Explorer could be the best vehicle for you. If you just liked cruising country roads with the top down, the Miata would be far better.

        With your problems, if sharing memory was the most important criterion, I might investigate using a single task driving a set of state machines. Depending on what you're trying to do, this might give you the best performance with everything shared. If you share only a little bit of data--but very frequently--then I might use threads. On the other hand, if you less frequently share more complicated data, then I might advise the use of forking and share the data via a database, an IPC class, or some such. Without context, it's quite easy to give advice that you'll find to be wrong for your situation.

        ...roboticus

        Update: Oops! Minor edit: s/top down, would/top down, the Miata would/

[reply]
[d/l]
Re: issue of concurrency: which module is better
by locked_user sundialsvc4 (Abbot) on Oct 08, 2010 at 18:18 UTC

    There is also the element of how you choose to use threads (or processes) in your application.   These things are best, IMHO, when they are created once, and then continue to exist for a long time.   Quite a few folks, though, use the “flaming-arrow approach,” where they create a new thread and just fire it into the air ...   There is much grousing about performance when the real issue, again IMHO, is that “there are too damm many threads alive at once.”

Back to Seekers of Perl Wisdom