Rename spawn function

[oxinabox]

The spawn function is the same as the run function but non-blocking, it runs the process in the background.

The better known @spawn macro, is used to run a function on a different julia process.

While conceptually related they are not related in any practical sense.

I suggest that spawn(cmd) should be deprecated to something like run_background(cmd),
or to run(cmd; background=true)

[KristofferC]

I like the keyword argument one.

[StefanKarpinski]

I believe that makes run type unstable but that's probably fine. If you're forking a subprocess I don't think you care much about a little type instability, and of course the usual behavior is to ignore the output of run so it probably doesn't even matter what it returns most of the time.

[stevengj]

Since run currently returns nothing, I don't suppose it would hurt to change it to return Process(cmd, ProcessExited(0)) to be similar to spawn.

[StefanKarpinski]

The keyword argument could be wait::Bool=true so you could get the effect of spawn by doing p = run(cmd, wait=false). It could sometimes be handy to get the process object and wait for it.

[StefanKarpinski]

Another option: let this be type unstable and return the process only when wait=false is passed.

[StefanKarpinski]

Alternate idea:

• implement open_flag types keywords for open(cmd) (we should do this anyway)
• deprecate spawn(cmd) to open(cmd, read=false)

[StefanKarpinski]

spawn also has a ton of undocumented methods that shouldn't be public. My proposal is to unexport spawn and deprecate the 1-arg documented method to open(cmd, read=false).

[JeffBezanson]

After starting to work on implementing this, using open seems a little odd. In open(cmd, read=false) you're not actually opening anything. While open should support read and write keyword arguments, and the right behavior falls out of read = false, it might be good to allow using a more obvious verb like run for code readability.

[PallHaraldsson]

"If you're forking a subprocess I don't think you care much about a little type instability"

I would like type stability in general; or that is no allocations, e.g. for that function. [Any idea if allocations/type instability is common in the standard library; at least in basic functions where is seemingly could be avoid?]

Maybe I'm mistaken about the reason: it even happens (in 0.5) for type stable functions (always a problem with type instability?), as I get in the global scope, even for @time trivial_function() "4 allocations: 160 bytes".

I'm thinking of real-time use of Julia. Then you want no allocations, and even some few exceptions with low amounts could derail it (and low/infrequent is easy to miss).

Of course spawn would allocate memory for the new process, but shouldn't need to do it for the current one?

[In general, debugging, or preventing allocations/GC is a broader issue than this one; I'm just thinking, can this be done here?]

[JeffBezanson]

Type stability and allocations are separate issues, only sometimes related. The approach we ended up implementing here is in fact type stable, but still needs to allocate a process object. I don't think allocating a tiny process object should be a big deal, when you're already doing something as heavyweight as starting a new process in a multi-tasking OS. Real-time GCs exist, so even real-time applications do not entirely rule out memory allocation.

[quinnj]

So this is breaking for spawn(cmd::Cmd, stdios::Tuple{Union{Base.FileRedirect, IO, Ptr{Void}, RawFD},Union{Base.FileRedirect, IO, Ptr{Void}, RawFD},Union{Base.FileRedirect, IO, Ptr{Void}, RawFD}}; chain) in Base at process.jl:506, is there a recommended deprecation for that use-case?

[quinnj]

nvm, I believe run(pipeline(cmd, stdin=devnull, stdout=out_pipe, stderr=err_pipe); wait=false) is what I'm looking for.