Hi, What factors will you look for, to choose implementing a feature as multi-threaded vs using a single separate process.
What the target OS is: On Unix I am more likely to think in processes
What language I am writing in: In languages with good support for threads, I am more likely to want threads
How much isolation I want
How easy it is to use inter-process communication in my target language
I personally treat threads as things to be avoided as much as possible, preferring multi-process solutions as much as possible. The distinction, though, is how separable the work units involved are.
On Windows, with its lack of fork(), I'm more likely to use a multithreaded model than a multiprocess model for variant instances of the same worker (such as Apache handlers or agent processes that represent more than one thing but work similarly in other respects). On Unix, I'd be more inclined to use multiprocess for almost everything except small worker threads (especially in GUIs to keep the UI responsive). In cross-platform work, I'd use multithreaded because of the limitations of Windows.
How much sharing of resources is required ? Shared memory is free for threads, but subject to the usual resource contention issues.
Message passing (consider MPI?) vs shared memory . Also consider task time vs process start up overhead vs thread start up overhead.
I think it all depends on the coupling, typically inter thread communication and synchronization (think mutexes, thinkg shared memory) is much more simpler than inter process communication (think sockets, think networking, think pipes, think mailboxes), so when you're logically grouping functionality I would go for threads.
However when you need to have an application which scales cross systems (think distributed) or which has much proper locking or where the division between entities is much more strict than only logically grouping I would go for processess.
Personally I'd need a very good reason to use multiple processes instead of multi threading.