Or, another "simpler" option is to stick to POSIX spawn.  That is, it always run the process concurrently (not wait), and returns pid.
We may leave spawn_file_action and spawnattr to implementation-dependent  "config" argument, if we don't want to get into too much
details.  We could say "pid"---returned from fork and spawn, and can be passed to wait---is an implementation-dependent object
so that we can use process handles on Windows. 

On Mon, Jul 1, 2019 at 9:22 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
If wait watis on pid I don't think you need to search and update corresponding process object. It's like closing fd bypassing FILE*. 
We assume progammers know what they're doing.

I agree that we don't want to complicate things, but in this case, just wrapping pid (or process handle, on Windows) and exit status
in an opaque object and use it throughout process-related APIs looks simpler to me.   Some procedures, like wait or kill (which isn't in srfi-170),
may take both proc object and pid.   If pid is passed, a caller is messing under the hood and knows what she's doing, so we don't care
about process objects.







On Mon, Jul 1, 2019 at 1:19 AM John Cowan <xxxxxx@ccil.org> wrote:


On Mon, Jul 1, 2019 at 6:32 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

We already have an opaque process object so I don't see a reason spawn can't return it as well.  Is there a platform
that's difficult to implement spawn to return it?

Currently the process object does not compel the implementation to keep the exit code alive after waiting, and I would rather not require it to do so, as this complicates the execution model.  A wait operation performed on a raw pid (which is allowed) would have to find the corresponding proc object and install the exit code in it.  Of course one fix would be to forbid waiting on a raw pid.

Furthermore, the actual pid is no longer valid after wait; the OS may reuse it freely.  I would rather treat a waited-for proc object like a closed port: not really useful for anything.

I don't like spawn returns
different type of object depending on whether it waits for the process to exit or it runs the process asynchronously.

I agree in principle. However, to separate spawn/wait from the other two just to keep the return type fixed means having 16 spawn procedures instead of 8.  That seems to me excessive.

I thought it would be consistent that spawn returns a process object, from which the exit status can be retrieved (by wait).

I would rather have wait always wait and return the exit code, and retrieve the exit code later on by proc:exit-code (which would return #f if the exit code is not yet known).  But as I say I am not convinced that this is the right model.

On Mon, Jul 1, 2019 at 6:55 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

That leads to the question: should not-yet-spawned and spawned processes 
be the same type of object, and do we even need to specify that.

I don't even know what a process object for a process that has not been created yet would look like.  Or do you mean "not-yet-waited-for"?  In which case my answer is sketched above.


John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
May the hair on your toes never fall out!  --Thorin Oakenshield (to Bilbo)