Re^3: Threading vs perl

forking off the process to do the job would be the best.

Do you realize that forking is very much different from threading? Fork actually copy the memory from one process to another, causing more memory use. A forked proccess can only comunicate with the parent process with IPC and shared memort. With threads the memory *is* shared, and you don't need to handle that.

The question is that there are uses for fork and for threads, and using threads when forking is better is as bad as using fork when threading is better. Do you want an example?

First: Implementing a networking application that needs to continuosly read and continuosly write from sockets. It can be done with fork, but it would be much better (from an OS view) to do with threads.

Second: JBOSS uses too much threads and too few forks. The result is that I can easily see it eating 900 Mb of RAM beause of some jobs that uses more memory, if it did fork, these procesess that eat memory would run in a forked procecss and the memory would be given back to the Operating System.

I think there is no way to say "Why do I need threads, since I have fork?"... It's the same to say "Why do I need a car, since I have a stomach?"...

daniel

Comment on Re^3: Threading vs perl

Replies are listed 'Best First'.
Re^4: Threading vs perl by chromatic (Archbishop) on Jun 20, 2005 at 18:00 UTC
Fork actually copy the memory from one process to another That depends on the operating system. I don't know of any Unix-like OSes worth using that don't have copy-on-write for forking. With threads the memory is* shared* That depends on the threading model. With a shared-everything model, threads can safely share most of everything (except for parts of the execution context). Of course, then you have the potential for deadlocks and weird execution order if you want atomic operations where it matters. With a shared-almost-nothing model, you won't even have the potential memory savings of copy-on-write unless the implementors did a lot of work. if it did fork, these procesess that eat memory would run in a forked procecss and the memory would be given back to the Operating System. The OS should reclaim the copied memory pages, yes, but not the shared memory pages.	[reply]

Replies are listed 'Best First'.

Re^4: Threading vs perl
by chromatic (Archbishop) on Jun 20, 2005 at 18:00 UTC

Fork actually copy the memory from one process to another

That depends on the operating system. I don't know of any Unix-like OSes worth using that don't have copy-on-write for forking.

With threads the memory *is* shared

That depends on the threading model. With a shared-everything model, threads can safely share most of everything (except for parts of the execution context). Of course, then you have the potential for deadlocks and weird execution order if you want atomic operations where it matters. With a shared-almost-nothing model, you won't even have the potential memory savings of copy-on-write unless the implementors did a lot of work.

if it did fork, these procesess that eat memory would run in a forked procecss and the memory would be given back to the Operating System.

The OS should reclaim the copied memory pages, yes, but not the shared memory pages.

[reply]