Threads or Forking?

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

Replies are listed 'Best First'.
Re: Threads or Forking? by cmeyer (Pilgrim) on Jul 29, 2005 at 00:10 UTC
If you would like to share large amounts of read-only memory between the processes (read: threads or processes), then fork is your choice. Perl's ithreads implementation doesn't support truly shared memory, or COW (copy-on-write) shared memory. On the other hand, if you want to share large amounts of read-write memory, or if you want to share objects between the processes, then there is no reasonable option that I am aware of. The best option that I've found for communicating complex data structures between processes is serializing the data and printing it over a socket or pipe. The best option for sharing objects may be SOAP, RPC::PlServer, or something similarly obnoxious (or beautiful, depending on your point of view). I would love to learn that I am wrong about this. -Colin. WHITEPAGES.COM \| INC	[reply]
Re^2: Threads or Forking? by mugwumpjism (Hermit) on Jul 29, 2005 at 00:40 UTC
Of course databases are the "usual" way to share state between concurrent processes. All the hard problems are already solved that way... $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n"; [download]	[reply] [d/l]
Re: Threads or Forking? by japh (Friar) on Jul 29, 2005 at 01:46 UTC
Forking is expensive, because every forked instance of your program is a full running copy of the original process, but is supported (or at least emulated) in every OS with POSIX support. Threading is a steeper learning curve and is less universal than forking, but takes minimal resources in comparison. Threading and socket polling let you do things like thousand-connection-a second web servers. Node (and replies) reparented from duplicate thread Reaped: Threads or Forking? by Arunbear	[reply]
Re^2: Threads or Forking? by monarch (Priest) on Jul 29, 2005 at 04:52 UTC
..although forking CAN be cheap in certain conditions. Often an OS will pretend to make a copy of the memory used by the 1st application, but won't ACTUALLY make a copy until that copy needs to change. Which is pretty clever I think!	[reply]
Re^2: Threads or Forking? by Anonymous Monk on Jul 29, 2005 at 11:57 UTC
On modern OSses, you know, those OSses modern enough to support threads, a fork copies the memory space of program as COW (Copy On Write) - space for copies of the pages in memory are claimed, but the pages aren't copied yet. They will only be copied if either the parent, or the child writes to that page.	[reply]
Re^3: Threads or Forking? by BrowserUk (Patriarch) on Jul 30, 2005 at 01:28 UTC
But remember this. Read-only at the Perl level does not mean read-only at the C-level. With COW, If you use a read-only variable, that is a number read from a file, in a calculation, the IV or NV field of that variable will be written to and the 4k page containing that scalar will have to be copied. If you take a reference to a read-only scalar, the flags field in that scalar will be updated and the 4k page will be copied. And there are a dozen or so other flags and fields that can be modifed as a result of Perl-level read accesses to a scalar, hash or array that will cause pages to be copied. 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^2: Threads or Forking? by chromatic (Archbishop) on Jul 29, 2005 at 17:34 UTC
Threading in Perl does not take minimal resources in comparison, especially on a COW platform.	[reply]
Re: Threads or Forking? by xdg (Monsignor) on Jul 29, 2005 at 02:00 UTC
It's well worth looking at Things you need to know before programming Perl ithreads. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^2: Threads or Forking? by BrowserUk (Patriarch) on Jul 29, 2005 at 18:52 UTC
And when you've read that, read this subthread and then make your own mind up on the basis rational discussion rather than dogma. I guess the real question is, in what cases would I using forking over threads? The first thing you need to realise is that, whilst there is some overlap in potential application, forks and threads are different--each having it's streangths and weakness. Learning about those differences, and considering your application in light of them will save you much time and pain. BTW. The Thread module is obsolete unless you using an old version of Perl. If you are considering threads, then you need to look at and use threads. 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: Threads or Forking? by zentara (Cardinal) on Jul 29, 2005 at 12:27 UTC
Threads make sharing data between threads and the main program easy, it's not-so-easy when forking. So if you need data-sharing between the processes(or threads) while they are running, use threads. Otherwise fork. I'm not really a human, but I play one on earth. flash japh Node reparented from duplicate thread Reaped: Threads or Forking? by Arunbear	[reply]


Perl: the Markov chain saw
	PerlMonks