On 2/8/2020 8:58 AM, Bertrand Augereau wrote:
The 1st value returned by (subprocess) is an opaque reference to
the executing process. If you pass the reference to
(subprocess-status) it will return *'running* if the process
currently is executing, or the exit/error value.
"exit/error value" is the issue there.
(subprocess-status ps) will return 'running if the process is running.
If it doesn't, either the process has never ran, either it has
finished with a exit code.
No way (that I see) to disambiguate.
I'm not sure I completely understand the problem. You're correct that
there's no way to tell whether the value is an exit code from the
program or an error from the operating system ... but there also is no
way to tell that starting the program from the shell IF you rely
solely on the exit code.
But if the idea is to tell whether the program started correctly - even
if it since has ended - then something like:
(eq? 'running (subprocess-status ps))
(not (= 0 (subprocess-pid ps)))
should do the trick.
(subprocess-pid) is only valid when (subprocess-status) is 'running
but testing the status then requesting the pid is not atomic,
therefore subprocess-pid should return #f or raise. Or return pid 0
but it should be documented :)
It does return 0 if the program never started.
I won't argue about documentation, but I will note that the Racket
"process" object retains the assigned pid value even after the process
terminates ... so testing whether it is running before retrieving the
pid does not seem to be a real burden. Do you have a use case where
By the way there is a process with pid 0 on Linux, it's "sched". And
on Windows, its "idle". Of course it could never be the result of
(subprocess ...) but I don't want to rely on incidental behaviour from
an API :=
Those are not processes - they are kernel functions called when no
actual process is ready to run. They consume time and CPU cycles, so
they are included in the process listing, but they really are just
system overhead. When the OS is in one of these functions it is
sleeping waiting for either a timer tick or an I/O completion.
And pid 0 will never be assigned to a real process.
Hope this helps,
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit