Shell properties - please comment

Interesting idea, but i'm wondering if it goes far enough. Your saying that each shell would get its own set of properties, independent of other shells and sub-shells. But what about multiple 'processes' that are spawned by the same shell concurrently that try to alter those properties. Would this still not introduce the same race conditions for properties that exist with the system properties? Normally one would consider this the realm of environment variables, as, if im correct in this assumption, on a system like linux, each process gets its own copy of the env variables to work with. But the problem with env variables is that the jdk classes do not use the environment, they use the properties. One glaring example is that java.io.File uses the property "user.dir". Under the current system, if i had 4 shells open, `cd somewhere` would cause all 4 shells to go there. A change like this would fix that issue, but what about if i were to have half a dozen commands in a pipeline, and they were to modify properties, or if i were to send a process to the background(i know this doesnt work yet), would this have, and modify, the same properties as its shell?

Mostly what im trying to get at is, i believe this is something that needs to be done at the Isolate level. Which would include shells, as they would be within their own isolate, but would also included every 'process' the shell spawned, and would also include those that are not spawned by shells. Im not sure if the idea down the road is to have even a 'gui' setup to have its own 'shell' type that was not a command line. But we have to also consider that applications launched from within a gui context are going to expect to have their own System properties.

To sum it all up. I think the proper solution is to 'isolate' system properties, and have everything spawn in its own isolate. Of course this means that isolates have to be worked on and stabilized. But this is something we 'really really need'. Fixing isolates and putting things like this inside its realm is, IMO, the proper path.

P.S. spare me a little if i seem like im totally rambling, im a bit under the weather

Cluster: Shell properties are not intended as the solution to the "user.dir" problem. The solution to that problem is either to procletize 'System.getProperties()' ... or Levente's more complex alternative. Shell properties are not for general use by "processes" (by which I guess you mean command instances ...).

I'll assume that 'System.getProperties()' has been procletized, and that by "process" you mean an executing command class. (We don't have a single "process" notion in JNode terminology ... we have a continuum corresponding to the 4 different invokers, plus potentially others ... like maybe an invoker to run a command on a remote JNode machine. But I digress.)

If a command is launched by the (currently not working) IsolateInvoker, it will get a copy of the System properties in effect for the parent shell / interpreter, and a new System environment populated with the parent interpreter's variables. It will be able to change "user.dir", but only in its own copy of the System properties. That won't affect other commands running in other isolates.

If a command is launched by the ProcletInvoker, it will have its own procletized copy of the System properties in effect for the parent shell / interpreter. This will make it immune from other commands, or its parent shell changing the current directory ... as for the IsolateInvoker case.

If a command is launched by one of the two primitive invokers, it will share System properties with other stuff in the same isolate, and will be open to having its "current directory" changed without warning.

I think you have put your finger on an issue though. If there are multiple CommandShells in an isolate ... or multiple interpreter contexts (i.e. subshells in POSIX speak), we have stop one shell / subshell running the "cd" command from affecting the other shell / subshells. The simplest solution is for each shell / subshell to be executed in its own proclet. Another option (for subshells) is for each interpreter to maintain its own notion of the current directory in the interpreter context objects (e.g. BjorneContext) and copy this to the "user.dir" System property of a child command instance while invoking it.

And just for the record, we don't plan to ditch proclets when isolates are fully implemented. There is a general view that proclets are likely to be significantly better for some use-cases than isolates (and vice versa of course). If this view proves to be wrong, then we (IMO) should ditch proclets.

Regarding proclets. Perhaps i was a little forward with the idea of 'ditching' them. It's not totally what i meant but i wasn't clear about that. My objection to proclets comes more from a maintainers point of view. In general, the fewer systems there are to maintain, the easier it is to maintain. Its a bit of an obvious statement but i think sometimes it can get overlooked. Isolates are _needed_, proclets are not. Proclets are not a bad thing, but they should be considered an add-on feature. This is in effect one major difference between the common 'process' that exists on other systems, and jnode's invoker interface. This is why i felt the discussion of wether or not to add features(sysprops) to proclets was a bit moot. Isolates should be the only concern of jnode, and any other invoker should be outside the realm of 'vanilla'.

Git actually has a wonderful feature for doing this called submodules. Though i dont believe they play well when intefacing with svn, as svn cripples most of the advanced features of git.

As for the shell props, i see what your doing now and i mistook it as something else is all.

Isolates are _needed_, proclets are not. Proclets are not a bad thing, but they should be considered an add-on feature.

You need to read some history. For example this topic from April 2007 is where I first raised the idea of proclets. Though the article does not spell this out (I was trying to be diplomatic!!) my real motivation was to get past the roadblock of isolate implementation. At that time, isolates were unusable and no progress had been made in a long time. This was holding up any possibility of making consoles / shells / commands work properly. Proclets were the only way I could see to make progress.

While the isolate implementation has moved forward, everyone acknowledges that isolate support is still not complete. (Indeed, it is broken at the moment according to Levente.) Until isolates / isolate launching works reliably, proclets are needed to safely run more than one application / shell at a time, implement stream redirection / pipes, and various other things.

Even when isolates and isolate launching are completed, we still suspect that proclets will be worth keeping. In some cases we suspect that they will be needed ... in the sense that they will allow us to implement things (e.g. meet performance requirements) that may be impossible to meet by running the same commands in isolates. But this is conjecture. But so is your statement that they (will be) not needed.

Personally, I would like to be able to throw away proclets. While proclets don't change JDK APIs, they cause some things to behave in unexpected ways, and will break certain applications as a result. But if isolates turn out to be as costly as we suspect, I think that proclets will continue to be a necessary evil.

In short, to describe proclets as an unnecessary add-on is to misunderstand their purpose, and to rewrite history.

This is why i felt the discussion of wether or not to add features(sysprops) to proclets was a bit moot.

You are assuming that isolates will be completed soon. Based on past history, I'd say that is a wildly optimistic assumption.

[Aside (updated): notwithstanding what Levente implied on IRC ... if you don't start the proclet mechanism in an isolate, the performance impact of having proclet support should be almost unmeasurable. It consists of an extra indirection and procedure call via the so-called IOContext object for some System methods (setIn, setOut, setErr, the property methods and the env methods) that are not likely to be called often. If an isolate doesn't switch on the proclet mechanism, all of the expensive and complicated ProcletProxyStream objects and other stuff simply never get instantiated.

Similarly, the proclet implementation is pretty isolated from the rest of the JNode codebase. If you were to snip out the org.jnode.shell.proclet package, you might not even see any compilation errors! You'd just be left with the IOContext isolation layer, which is (as mentioned above) almost unnoticeable. Admittedly, the proxy stream code is pretty complicated, and not cheap to use. But it will only hit applications that use System.in/out/err (as distinct from the CommandIO streams, etc).]

Back on topic with shell props.

There is one small issue. Bjorne's builtin 'set' does not let you set the jnode.interpreter shell prop, so once you've set it to bjorne you can't go back to redirecting or some other interpreter.

Bug. Will fix. Thanks.

The other answer is ... "why would ever want to go back?"

Update: I've created a separate issue for this bug.

Since, the patch has been committed, I'm marking this issue as fixed.

Manually closed.