[Truffle] Minimal Java POSIX #3615
Conversation
|
|
||
| @Override | ||
| public int getpid() { | ||
| return context.hashCode(); |
There was a problem hiding this comment.
This is how JRuby does it. There doesn't appear to be any other way to get the PID, and at least the may deconflict between multiple contexts in the same VM.
There was a problem hiding this comment.
there's an ugly way to read and parse from a management bean ... assuming that is fine to pull in jmx
There was a problem hiding this comment.
Yes thanks, but the point of this little project is to be totally pure Java and I think that bean name is implementation defined. We'll only use this in very limited cases - we normally require a native POSIX and won't run with the fallback.
|
What does this gain us over just using the Java layer already in jnr-posix? Just faster turnaround? |
|
The existing Basically we can't boot with |
|
Can we add what you need to JavaPOSIX? Do we really need to make another
POSIX abstraction?
|
|
I'm not sure all the changes I'll make will be safe for general use - they might be quite tied to what the Rubinius code runs. When I get everything I need running I'll reconsider and put stuff back into jar-posix where I can. |
|
So far it looks like most of this stuff (except probably getpid but then we could special-case that one) would be fine for JavaPOSIX, it's already doing this kind of "best-effort" implementation from what I recall. |
[Truffle] Minimal Java POSIX
When we adopted Rubinius' kernel, we lost the ability to run without a real native implementation of
POSIX. This is some work towards getting that ability back, by using knowledge of what Rubinius really tries to do with POSIX to provide a Java emulation that will work for us.This PR gets us as far as loading, but not doing
puts.@nirvdrum