SQL Server Integration Services (SSIS) functionality is wrapped up in packages. A package is the SSIS executable. A package can contain a task called the "Execute Package Task" which enables you to execute a different package from within a currently executing package. The package containing the "Execute Package Task" is referred to as the master package. The package being called is referred to as the child package.
The "Execute Package Task" provides the capability for a child package to be executed in-process or out-of-process by use of the ExecuteOutOfProcess property. A child package that is executed out-of-process will result in a new process being started in which the package is executed. To quote BOL, the ExecuteOutOfProcess property is used to "Specify whether child package runs in the process of the parent package or in a separate process".
If a child package is executed out-of-process, the resultant OS process is called dtshost.exe. So, if you are executing many child packages from within BIDS using debugging you should be able to see many instances of dtshost.exe running in Windows Task Manager and these processes will remain "live", using up resources, for quite a while after execution is complete. I have witnessed shutdown times of minutes rather than seconds when many of these processes are executing. Note that this is in part down to the vagaries of managed code and the problem is not quite as prevelant when the master package is executed from BIDS without debugging.
I recently raised a question on the beta newsgroups relating to whether or not a child package should be executed in-process or out-of-process. Michael Entin from Microsoft provided some excellent answers. To summarise here:
-If executing in-process, a bug in a task of the child package will cause the master package to fail. Not so if executing out-of-process.
-On 32bit systems a process is able to consume up to 2GB* of virtual memory. Executing out-of-process means each process can claim its own 2GB portion of virtual memory.
Michael therefore recommends that if you are simply using many packages to struture your solution in a more modular fashion, executing in-process is probably the way to go because you don't have the overhead of launching more processes. I'm happy to pass on that advice here.
-Jamie
*3Gb if you boot with /3Gb switch in boot.ini