Implemented getpid(p::Process).

[abalkin]

Closes #4752.

[rfourquet]

What about alternatives when the process is not running, like throwing, or returning nothing ?

[abalkin]

Returning nothing would violate type stability. Throwing is an option, but I feel returning -1is more convenient. There was also a suggestion to save the pid so that it can be inspected after the process has ended. I don't think this is a good idea because pids can be reused and having getpid(p) return a potentially unrelated pid is error prone. (E.g. you don't want to accidentally kill an unrelated process.)

Also, as @vtjnash mentioned before, we can take guidance from nodejs where child pid is accessible via a property which does not throw.

[abalkin]

I ran an experiment with node, and it looks like they cache the pid:

> const { spawn } = require('child_process');
> x = spawn('sleep',  ['1']);
> x.exitCode
0
> x._handle
null
> x.pid
45660

I still don't think this is a good idea for the reasons I mentioned above.

[vtjnash]

I think this is essentially the same question as #18145. But upon reflection, I think an error would be better here. In some places, -1 is used as a special value to mean "all processes". So kill(getpid(p)) could accidentally cause the system to reboot (surprise!) with this choice of sentinel value.

[abalkin]

Fair enough. I'll make the change. Just to make sure: caching the pid is off the table.

[rfourquet]

nothing may make it type unstable, but this seems to be the new way of returning what was a Nullable (ie. returning Union{T, Void} or Union{Some{T},Void}), and getpid is a function for which I would tend to return a Nullable.

[rfourquet]

Why not return Int?
EDIT: oh I see, getpid() returns Int32 already, but still...

[abalkin]

Right. I just copied that line from the Base.getpid() doc. The actual type is Cint, but I think that is the same as Int32 on all the supported platforms.

[vtjnash]

Yes, this was the right choice (matching getpid())

[rfourquet]

What about changing that to Int for both methods in another PR? for example, one method of kill (with ClusterManager) accepts a pid as Int.

[abalkin]

@rfourquet - isn't that a different ID? I thought kill(::ClusterManager, ..) takes the worker id, not the OS process id.

[rfourquet]

It seems you are right.

[Keno]

This seems to have fallen through the cracks, but seems fine to me. @vtjnash ?

[StefanKarpinski]

Somewhat tangential to this, but I think that we should use Int for process IDs.

[stevengj]

Bump

[stevengj]

Rebased.

[JeffBezanson]

Our getpid is actually Libc.getpid. Should we add a method to that (even though such a signature doesn't exist in libc)?

[iamed2]

Our getpid is actually Libc.getpid. Should we add a method to that (even though such a signature doesn't exist in libc)?

I think it would make sense to have the Libc getpid extend Base.getpid. If there are further uses for getpid that don't use Libc (e.g., some package implements some other process management system) it'll look weird to have to extend it from there again.

[JeffBezanson]

Well, we don't really have a way to do that exactly. Base.getpid and Libc.getpid are either the same function or two functions.

[iamed2]

Oh, I meant make them the same function but put it in the Base namespace rather than Libc

[stevengj]

@IAMED, other packages can already extend it via Base.pid(...) = ..., no? So it's not clear to me how it matters in practice if it's defined first in Base or Libc.

[iamed2]

Oh you're right, my bad, that's something good for me to remember in the future. Sorry to muddy the waters.

[vtjnash]

Thanks for the PR! Sorry it took us such a long time to land.