From: Kent Friis <nospam@...>
Date: 2009-08-23T08:30:14+09:00
Subject: Re: Process or Thread?

Den Sat, 22 Aug 2009 09:30:36 -0500 skrev Pito Salas:
> I have a parent application (which I think of as a test harness) that
> wants to invoke a fairly intensive image processing application against
> a directory full of image files. Each image is processed independently.
>
> So, to get performance, I wanted to get the work happening on each of
> those images in parallel. So I could divide the files in the directory
> into two sets, and submit one set for processing in one process/thread
> and the other set in another process/thread. Note that the
> sub-process/threads are almost totally separate from the parent app, so
> relatively little information needs to go back and forth.
>
> Here is what I've learned so far from reading two books and lots of
> googling:
>
> One point is that there's no process support on Windows, which isn't a
> deal killer for me.

Not quite. Look in Task Manager, there is a list of processes running.
What Windows possibly lacks is fork(), the unix way of creating
processes. It does however have CreateProcess (I think that's what
is called), which behaves like fork+exec.

If you split the "controller" process and the "worker" process into
two different programs, it won't be a problem. If you insist on
having them as one program, you'll need to do a bit more work
(add a comamnd line argument telling the new process that it's a
worker process).

> Another point is the operation on multi-core CPUs: processes will, and
> threads will not use the mutliple cores. This too is fairly "don't care"
> for me.

Native threads will, Ruby green threads won't.

> I am interested in ease of implementation and debugging.

Debugging is lots easier with processes, as one process cannot
accidentally overwrite data of another (shared memory is possible,
but needs to be allocated explicitly).

That may not be as big a problem with Ruby green threads, as the
runtime knows what each thread is up to.

> And I am also
> very interested in getting the cpu and disk active at the same time as
> there is a fairly large amount of data to be read form the disk.
>
> What are your recommendations?

I would go for processes. But that's coming from C, where there is no
runtime keeping track of what each thread is doing. With processes,
the OS will prevent one OS from overwriting the data of another.

/Kent
-- 
"The Brothers are History"