[brailleblaster] Re: more on spawning processes

  • From: "qubit" <lauraeaves@xxxxxxxxx>
  • To: <brailleblaster@xxxxxxxxxxxxx>
  • Date: Wed, 8 Dec 2010 12:07:33 -0600

Mike, as I pointed out, if you look closer, the return type for the input 
method should be an output stream for the java process, and the return type 
for the output methods should be input streams.  The documentation specifies 
this inconsistently.  It makes standard error of the subprocess go to an 
input stream (correctly), but the standard input of the subprocess goes to 
an input stream (wrong), and the standard output goes to an output stream 
(also bogus).
The docs are wrong but also inconsistent, as they handle stderr one way and 
stdout another.

Anyway, I note these are also abstract methods so I need to find class 
implementations that will handle whatever platform I am using.
Honestly, I know how to do the pipe juggling in the process of spawning a 
child process, as I have done it before a number of times -- but in unix it 
is easy using fork and exec, but I am not shure what to call for windows, 
and for that matter, whether this differs between versions of windows.

I also thought about the performance issue, so I may in the end go back and 
finish doing the jni, but I want to investigate this as well because it is 
cleaner and opens up the possibility of dropping in other spawned processes 
without much effort.
--le

----- Original Message ----- 
From: "Michael Whapples" <mwhapples@xxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Tuesday, December 07, 2010 7:10 PM
Subject: [brailleblaster] Re: more on spawning processes


Firstly that is good news for you on the family front and I hope it all
goes well.

Regarding using itex2mml, using pipes probably will work fine for
actually getting the data, however I would imagine it will be much
slower than using JNI. Basically be prepared if a bottleneck appears at
that point to look at moving to JNI. In short what I am saying, try and
make an interface to that part of the code which will be independent of
how itex2mml is run (eg. don't have it that the command line flags are
passed about more than necessary, may be have a different method for
each way itex2mml will be called).

There is no inconsistency regarding the streams of java.lang.Process.
Reading the full documentation of those methods, getErrorStream relates
to the processes STDERR stream, getInputStream relates to the processes
STDOUT and getOutputStream relates to the processes STDIN. The methods
are named for the perspective of the java application, I pass data out
to the process and get data back in from the process. The application
inside the process sees it the other way round.

Michael Whapples
On 07/12/10 23:17, qubit wrote:
> Wow, I'm just now this afternoon getting to the brailleblaster code.  I 
> had
> something important come up that I had to take care of all morning.
>
> Also, hope you don't mind an off topic announcement -- my niece is even 
> now
> in labor with her first baby.  It is a boy they will name Benjamin.  He
> should be arriving sometime tonight or tomorrow.  First baby in his
> generation.  It is very exciting -- so hope you'll forgive this diversion.
> But look at it this way -- you could say my niece is in the "spawning
> process".  (More seriously, happy thoughts and prayers if you say them are
> welcome.)
>
> Anyway, back to java, it appears that java defines a platform independent
> way of running a filter and feeding it input and collecting its output in
> buffers.  This will make it possible to run the itex2MML command 
> completely
> independently rather than cutting into the code to make a JNI library.
> Hopefully it can come in handy for other utilities as well.
>
> I did run across something that looks erroneous in the java class
> documentation online.  In particular, there are 3 functions that set up
> pipes to manage standard in, out and err:
>
> abstract InputStream getErrorStream()
>                Gets the error stream of the subprocess.
> abstract InputStream getInputStream()
>      gets the input stream of the subprocess
> abstract OutputStream getOutputStream()
>      get output stream of subprocess
>
> Note the return types are inconsistent.  The first declaration is right, 
> but
> the second and third should have swapped return types (if I'm interpreting
> this right).
>
> I haven't tried compiling any code yet as I'm still writing it.  I hope 
> this
> is the right approach.  I did a fair amount of googling and reading of
> opensource projects, but for our purposes, I think just using the process
> classes in java.lang is sufficient.
>
> Any objections send to the list.
> Thanx and happy hacking.
> --le
>
>



Other related posts: