I've read the draft #5, and dug a bit more on spawn. Here's my take:

The current spec of spawn directly reflects DOS/Windows spawn-family functions, which is not POSIX,

and IMO it's a wrapper of CraeteProcess as a half-baked solution to ease porting POSIX prorgams.

Even from my limited experience on working on Windows API, I learned to avoid using them, for

the lack of finer control severely limits their usefulness to very simple use cases.

I always call CreateProcess directly.

I second for providing spawn-like mechanism so that systems that lack fork() can call child process,

but I feel it excessive to have 8 procedures with limited usefulness that are not even POSIX at all.

(If it's "process" srfi it may be ok but this is "POSIX" srfi.)

Here are alternative suggestions.

- Drop spawn family, leave it on separate process srfi.

- Provide posix_spawn. The full options may be too much, so we may start with common denominator

of POSIX and Windows-functionality.

- Provide fork&exec as a higher-level procedure. No need to provide 8 variations as exec, for fork&exec

isn't directly correspond to POSIX API. Gauche uses this approach:

https://practical-scheme.net/gauche/man/?p=sys-fork-and-exec

We already have file-spawn, which is a high-level API without corresponding POSIX API.

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

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)