> 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. >
That's why CreateProcess and fork/exec return code. If I was coding this in C, I would have no issue, so I think the problem should be clearly addressed in Racket too. I don't see what the shell's got to do with it :) > > 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. > Yes in practice, it might be good enough. > > > (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? > You're using undocumented behaviour there, Plausible one though. But it's subject to change in the future so I'd prefer to address it and have the documentation changed by the Racket team so that my code is robust in the long run :) > 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. > Indeed, but if 0 is a magic number of sorts for subprocess-pid, it should be documented too. IMO, it would be cleaner to have subprocess returns #f or raise an exception if spawning the process fails. It would solve my initial problem and mimic what the C APIs do. The subprocess-pid would not need any further consideration then :) -- 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/CAHV%3D05otrEn%3DW1auy01870JVtVZrCpMsxCqypQxE0WY5q-Kz8g%40mail.gmail.com.