`call` asynchronously?

[hostilefork]

@okram

On Atronix R3 when I run call "zathura" the program runs asynchronously. When I do the same in Ren-C it waits for the program to terminate.

CALL is a specialization of a more basic CALL*, which forces it to wait:

/extensions/process/ext-process-init.reb#L58

So you can just use CALL* (which is itself a layer that does some usermode preprocessing over parameters before they get to CALL-INTERNAL*. For anything not performance-criticial, it's best to avoid trying to write it in C where it is harder to change, so the C code tries to keep it to the bare minimum of what's needed to expose the system functions).

There's actually some kind of interesting code going on here, glossing the command line differences between Windows and POSIX. Windows operates on the basis of one big command line string, while UNIX expects an array of individual elements.

So if you're on POSIX and call with a single string, the native code hooked to exec() and pipe() will call out to the usermode parse-command-to-argv*

And if you're on Windows and call with a block, the native code hooked to CreateProcess will call out to the usermode argv-block-to-command*

I've written about this and I think it's neat.

Open Your Mind: A COLLECT in PARSE Meditation

The first time I used CALL, I griped that it was somewhat unusable (with a complaint that basically everyone else who tried it had, my complaint was far from unique). I would have thought that if I said call {r3 --do "print {Hello}"} that it would "do what I meant". Instead, what it did was try and find an executable file whose name (including spaces and quotes) was r3 --do "print {Hello}", and run it. As crazy as that interpretation may seem on the surface, it actually came from a desire to …