Richard E Maine wrote:
>
> I'm not sure why not. I've never particularly associated the word 
> "spawn" with parallel programing, and I don't think it historically 
> has such an association. If I recall correctly, the VAX intrinsic for 
> running a program was something like LIB$SPAWN, so the general 
> (nonparallel) usage has a long history.
Very good points. Also, there's a lot of CS Unixy discussions about 
"fork vs spawn" (neither of which are necessarily parallel). See 
http://www.isi.edu/~faber/cs402/notes/lecture5.html for just one example.
> .... many sage words elided
>
> 1. How does the communication of data work? With a subroutine this is 
> relatively straightforward; the data is normally ...to a temporary 
> file, although in some environments things like shared memory can be 
> used (but that's more complicated). The issues of communication are a 
> big reason to go with a subroutine.
>
Sure, and depending on how you arrange the I/O (e.g. if the program 
being "encapsulated" does only formatted output) you may be adding 
potentially considerable error (even systems that do nice arithmetic may 
not necessarily do base conversion as close to perfectly as is possible 
... it can be computationally expensive....)
> ....
> If it takes a lot of work to get a program working as a subroutine, 
> then that can be a significant argument for not doing it.
>
Absolutely, as well as
> 3. Maintenance issues. If you have reasons for not wanting to touch 
> the code of the program, than that can be an overriding issue.
Although it's possible to mitigate this by changing the *original* (not 
just forking the source) to have a simpler main program which calls the 
new subroutine which is to be maintained into the future).

...
> the factors mentioned in item 3 above can make even a serious 
> consideration pretty short, but it isn't clear from the original post 
> whether this is the case or not.
>
Indeed, we're all very good at conjecturing at the situation ... but the 
OP probably has actual details ;>

-- 
Keith H. Bierman    [log in to unmask]
Sun Microsystems PAE                     | [log in to unmask]
12 Network Circle UMPK 12-325            | 650-352-4432 voice+fax
Menlo Park, California  94025            | sun internal 68207
http://blogs.sun.com/khb
<speaking for myself, not Sun*> Copyright 2005