Use libc::getpid() instead of using /proc for portability

[shymega]

Instead of using the current method of querying the /proc virtual FS, Lynea can instead, harness the libc method 'getpid()', and do a simple if conditional to check if PID == 1.

However, libc is classed as unsafe Rust code, and I'm not sure what your position on that is. In theory, we should be able to handle errors in a safe manner.

Side note - my init system, 'i', uses the libc method, and seems to work well. Need to add safety checks though, if possible.

On the other hand, using the native C libraries offers more portability across platforms - if Lynea was to ever reach that point of progression.

Thoughts?

EDIT: Fix URI for i libc code, I reorganised today. (2016/08/25)

[darthlukan]

While I agree that using the libc method would save some lines of code, I'm leery of introducing anything marked "unsafe." It's not that I don't trust that the devs who wrote the library to do a good job, I just hold more trust in the Rust developers who are the arbiters of "safe" versus "unsafe" modules. It's something to think about though.

[shymega]

Hello,

Brian Tomlinson notifications@github.com writes:

While I agree that using the libc method would save some lines of code, I'm leery of introducing anything marked "unsafe." It's not that I don't trust that the devs who wrote the library to do a good job, I just hold more trust in the Rust developers who are the arbiters of "safe" versus "unsafe" modules. It's something to think about though.

Yeah, I hear your concerns.

I agree that it does seem to be a little worrying to use unsafe modules, but yeah, it is something to think about for later usage.

Perhaps asking on the Rust IRC channel (irc.mozilla.org#rust) might be of use, or the forums, if you want to find out more about the safety of using libc::getpid(). :-)

Regards, Dom Rodriguez

[darthlukan]

It looks like rust::libc::getpid() just wraps libc's native getpid() which in turn does much of what I'm doing already. At this point, it's just a matter of whether or not it's worth it to pull in an unsafe library just so it can do what I've already done in order to save a few lines of code. I checked the sources for libc and there's some magic in there, but once you get down to it, it's looking for a filepointer.

So far as the portability argument, Rust runs on lots of platforms and using "pure" Rust means that Lynea can run on any of those with expected results. If we're going to say that C is portable on more platforms than Rust, what's next? Rewrite Lynea in C?

[shymega]

Agreed. You can close this, but we can also bear this in mind if a similar issue comes up in future.

[shymega]

Actually, I can close it.

[shymega]

It appears that stable Rust has a new function in the std::process module. Its called id, and I've tested it locally. It returns the current PID of the process, and doesn't require the use of unsafe{} functions.

Any thoughts?

Link to docs.

[shymega]

Just to clarify: I guess what I'm proposing is to use this function instead of the current code to get the current PID.

[darthlukan]

@shymega - Yeah, I'd much rather use std::process::id().

Now I just have to find the time to update the code here to match the draft spec, or at least my initial ideas for the next few iterations.