in reply to Why use threads over processes, or why use processes over threads?

Here's my take on it:

I learned perl using the Camel, starting at the beginning.. Threads have more coverage there than forking, in fact, forking is mentioned only as a way of doing interprocess communication. Which would make sense to me, were I aiming to create separate processes, which I havent wanted to do, yet.. (Actually I did once, but then I just split my program into two, and communicated using sockets, which was easier in the end..)

I don't come from a unix/C background, so I've no history of forks, the why and how of them, and since threading works fine for me, I'll continue to use it (both 5005 and ithreads)

None of this says if threads are better than forks, or vice versa, the only thing I know about forks is that it seems to be more difficult to communicate between forked processes (using Thread::Queue or shared vars in threads is easy..) So, no clue there.

I'd say, threads for self-contained programs in which the threaded bits need to communicate, and forks for extra processes which do something entirely separate.. I'd assume that people use forks for things I'd use threads for just because perl threads weren't seen as any good for a long time, but that's probably just my opinion :)

C.

(Nodes are threaded, not forked, here, makes perfect sense to me :)

  • Comment on Re: Why use threads over processes, or why use processes over threads?

Replies are listed 'Best First'.
Re: Re: Why use threads over processes, or why use processes over threads?
by pg (Canon) on Nov 11, 2003 at 08:35 UTC

    I did notice that, many people (not all) from a unix/c background, tend to use threads over processes. I believe this is largely because unix/c thread has been very mature for quite a long time already, and on the same page, fork has been obsoleted in lots of those people's mind for quite a long time.

    I acknowledge that Perl has its unique situation, however as Perl is largely based on c, I don't see a reason why Perl will not follow the same path, although the trend is just started.

    If I didn't observe it wrong, Perl creators are pushing the use of Perl thread, and the more mature perl thread is, the more of this kind of push will come from them.

[reply]

      I did notice that, many people (not all) from a unix/c background, tend to use threads over processes.

      I noticed the exact opposite.

      I acknowledge that Perl has its unique situation, however as Perl is largely based on c, I don't see a reason why Perl will not follow the same path, although the trend is just started.

      Perl copies the entire interpreter when a thread is created. This is slow, inefficient and memory consuming. With forking on the other hand, all the modern platforms use Copy-on-Write, meaning that most of the interpreter is never copied, but stays shared all the time. A fork is fast, efficient and by itself doesn't use a lot of memory.

      Perl's C roots have almost nothing to do with this all. Perl is VERY different from C. It just happens to have a few similar functions, and a syntax that to some looks much alike.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[reply]
      I was actually observing (in myself and others), the exact opposite, unix/c people tend to prefer forks over threads. (I don't belong to that group..)

      C.

[reply]

In Section Meditations