[PATCH 1/2] Trailing whitespace.

Yes, please!

- Daniel

I don't think this is the right direction for the system library to
go. The System library is supposed to expose generic OS independent
interfaces, not be a generic way for clients to get OS information.

Ultimately I think a better API would be to provide a generic class
which represents an executed operating system process, and includes
operations to wait for its completion, redirect its IO, communicate
with it, etc. This would be a big improvement over the current
monolithic function.

That said, designing and implementing that is more work. However, I'd
rather either see that done, or clients do their own process stuff,
than have the llvm::sys API expose operating system dependent
information.

- Daniel

Hi Daniel,

Daniel Dunbar <daniel <at> zuster.org> writes:

Ultimately I think a better API would be to provide a generic class
which represents an executed operating system process, and includes
operations to wait for its completion, redirect its IO, communicate
with it, etc. This would be a big improvement over the current
monolithic function.

I agree, but my application needs access to the process ID. So if
I'll start implementing such class, it'll have a getPID()
method or similar :slight_smile:

Hi Daniel,

Daniel Dunbar <daniel <at> zuster.org> writes:

Ultimately I think a better API would be to provide a generic class
which represents an executed operating system process, and includes
operations to wait for its completion, redirect its IO, communicate
with it, etc. This would be a big improvement over the current
monolithic function.

I agree, but my application needs access to the process ID. So if
I'll start implementing such class, it'll have a getPID()
method or similar :slight_smile:

Do you have to have it? You can't use the pid (assigned from as a
number) without going through another llvm::sys interface, so why
should it be exposed?

I don't personally care too much -- and favor pragmatism -- but it is
counter to the documented design of the system library:
http://llvm.org/docs/SystemLibrary.html

- Daniel

Daniel Dunbar <daniel <at> zuster.org> writes:

Do you have to have it? You can't use the pid (assigned from as a
number) without going through another llvm::sys interface, so why
should it be exposed?

I need to invoke an external program (gcore), which takes PID as
argument. On Windows I do something platform-specific, but that
also requires access to PID.

I'm currently rewriting this patch to also remove the duplication
between ExecuteAndWait and ExecuteNoWait.

I don't personally care too much -- and favor pragmatism -- but it is
counter to the documented design of the system library:
http://llvm.org/docs/SystemLibrary.html

A one-line GetPid() method is not so dangerous IMO.