Asynchronous IO is great, but in some applications it's not enough, and threads are better. This becomes especially useful in applications with GUIs. You can use Tk's "after" utility to simulate multitasking, but it ain't pretty. Using threads is much, much better, and far more comfortable.

Threads make it very easy and quick to share data between units of execution, unlike processes. When you have a manager-workers model that requires a lot of data to be passed around quickly, threads come in very useful.

Continuations won't come instead of threads. While they make "cooperative execution" possible, it's not what they really are for, as far as I understand. You still have to decide when to give up control, and with many paths of execution it's important that this is done quickly and efficiently.

It seems like people are taught GUI programming with threads and thats the reason for this this strange popularity among younger monks.

What is really fun is this, statements like "but it still needs threads." are really pleasing to some monks, while "why actually?" make them angry.

I can't really understand this,

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?"...

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.