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:

   (or
      (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 this matters?


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,
    George



--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8e8fa61b-92b4-b58a-5601-d7197a04ba84%40comcast.net.

Reply via email to