Output stream confusion when switching consoles + fix (v2)

Project:	JNode Core
Component:	Code
Category:	bug report
Priority:	normal
Assigned:	Stephen Crawley
Status:	closed

This patch addresses the problem via the previously described "proclet" approach. The patch includes proclet infrastructure and a new command invoker for the shell that launches applications as proclets. As a temporary measure, I've added a new system property "jnode.invoker", and changed the shell command loop to switch invokers when then the property changes.

The patch also fixes a couple of bugs in ThreadCommandInvoker:

If you attempt to redirect to a file that cannot be opened, the invoker launches the application with a null output stream.
If you try to run a 'pipeline' and one stage cannot be executed (e.g. because the command name is incorrect), the invoker continues with running the next pipeline stage.

The supplied patch introduces a regression. Running "dir jifs" in proclet mode throws a security exception. It boils down to a security check that in classic Java is designed to stop applets and the like from finding out about other threads via ThreadGroup.getParent(). I need some advice on how best to fix this.

In the long term we should also:

remove the TextConsole's switching of System.{out,err},
fix the invokers' handling of streams for apps launched via the "main(String[]) entry point, and
get rid of the strange bit of code in the invoker that (I think) treats typeahead as extra command line arguments.

The patch is against revision 3398 of the trunk.

Attachment	Size
issues_56	67.39 KB

#1

Submitted by Stephen Crawley on Mon, 08/20/2007 - 03:21.

Status:

active

» closed

This version of the patch has other problems ... I'm working on it.

#2

Submitted by Stephen Crawley on Mon, 08/20/2007 - 04:21.

This version of the patch deals with the regression in the previous one by tweaking some permissions in the FS tree. It also fixes another problem ... too embarrassing to go into Sad

#3

Submitted by lsantha on Mon, 08/20/2007 - 21:35.

I'm not sure yet about whether the org.jnode.vm package is the right place for the proclet related classes. As I see it proclets appear to be a feature which may or may not be included into a jnode distribution and they seem to be principally linked to the shell. Therefore what do you think about moving them to a pcakge like org.jnode.shell.proclet in the shell project? As such should proclets really define a new mode for the vm, as the newly introduced 'proclet mode' suggests?
Can you see any chance for refactoring this in such manner that we can keep the components apart from the core vm as long as they do not strictly need to be linked to it?

In my tests js still appears to be sending the output the the wrong console though I can see the improvement in the input side. Can you confirm that?

Thanks, Levente

#4

Submitted by Stephen Crawley on Tue, 08/21/2007 - 02:23.

The trouble with your suggestion is that proclets are intimately tied to the methods in VmSystem that are responsible for switching the System.* stream variables. I don't think it is possible to separate them to the extent that you want.

Apart from proclets, isolates are the only way to solve this problem. That, and getting rid of the thread invoker.

#5

Submitted by Stephen Crawley on Tue, 08/21/2007 - 02:39.

There was a bug in http://www.jnode.org/uploads/issues_56 that meant that proclet mode wan't being enabled for the proclet invoker. Were you testing that version or the http://www.jnode.org/uploads/issues_57 version?

My testing of 'js' from console #2 showed the outputs going to the right
place after I ran "set jnode.invoker proclet" to switch to the proclet-mode invoker. Can you tell what I should do to reproduce the problem you are seeing?

#6

Submitted by lsantha on Thu, 08/23/2007 - 21:11.

I've committed the patch issues_57 after a refactoring to move the proclet related classes from org.jnode.vm to the dedicated org.jnode.shell package. This was a fast solution for being able to commit your proclet related work in order to get the bjorne shell integration going. The proclet invoker is not enable by default yet.
The proclet invoker has a strange sideeffect that you can see by:
- freshly starting jnode and selecting all plugins in the boot menu, then press 'e' and edit the command line to enable kernel debugging by adding 'kdb' to the end. You also have to redirect the serial port output of vmware to a file or console in order to see it.
- open a new console in a new isolate by: console -n -i
- go the the new console and start up 'js'
- when 'js' starts up all output is sent to the logger of the kernel debugger and to the serial port, so you type in the new console and see all output in the kdb log and nothing in the console
I think the preliminary refactoring of the patch can be improved, for instance it would be good to investigate how to reduce the number of methods on org.jnode.vm.IOContext and so reduce the interaction between the vm and the proclet related code.

#7

Submitted by Stephen Crawley on Fri, 08/24/2007 - 02:46.

Thank you for committing the patch. Now I have to see how you did the refactoring that I thought was impossible Smiling

Thanks also for the bug report.

#8

Submitted by lsantha on Fri, 08/24/2007 - 04:27.

From the bugreport above one step was left out by mistake. Before starting the second console in a new isolate the jnode.invoker should be set to proclet.

#9

Submitted by Stephen Crawley on Mon, 09/10/2007 - 02:28.

I have a tentative fix for the problem reported by Levente in followups #6 and #8. However, the GC vs isolates problem means that I cannot definitively test them. (The "js" command is triggering a garbage collection on exit, and the GC is not completing in an isolate.)