Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2007

Tip: Looking for answers? Try searching our database.

external processes

Thread view: 
trstag75@yahoo.fr - 21 Feb 2007 19:45 GMT
Hi all,

I'd like to know what is a safe way to deal with
an external process which we're *sure* won't
be generating any output on stdout/stderr nor
expecting any output on stdin.

Do I still need to read the InputStream(s)?

Would there still be a risk of being blocked
during the read?

I'd like to avoid having to create a
new unnecessary thread (once again, it is know
for sure that the process won't generate anything
on stdout/stderr) just for reading a stream that
I know shall be empty.

Basically I'm calling a shell script whose whole
point is that it 'wraps' the command to be called,
redirecting stdout/stderr to files (and also making
sure that it shall not block if the wrapped
command happens to expect input on stdin).

So that very simple shell script I'm calling
cannot generate anything on stdout/stderr.
It is convenient in that it eliminates the potential
deadlocks explained in the Process class's
JavaDoc.

JavaDoc (JD) for the Process class :
JD: Because some native platforms only provide
JD: * limited buffer size for standard input and output streams,
failure
JD: * to promptly write the input stream or read the output stream of
JD: * the subprocess may cause the subprocess to block, and even
deadlock

I've read the JavaDoc for ProcessBuilder and Process
and apparently it doesn't mention if reading the InputStream(s)
is mandatory or not.

Any infos on this?
Gordon Beaton - 21 Feb 2007 20:35 GMT
> I'd like to know what is a safe way to deal with an external process
> which we're *sure* won't be generating any output on stdout/stderr
> nor expecting any output on stdin.
>
> Do I still need to read the InputStream(s)?

No.

> Would there still be a risk of being blocked
> during the read?

Since the block is caused by a buffer filling, there is no risk if
nothing is ever written.

Just don't forget that you still need to close all three streams (in,
out, err) at some point. There is a file descriptor associated with
each of them, and if you fail to close them you will run out
eventually.

/gordon

Signature

[ don't email me support questions or followups ]
g o r d o n  +  n e w s  @  b a l d e r 1 3 . s e

trstag75@yahoo.fr - 21 Feb 2007 20:56 GMT
> > I'd like to know what is a safe way to deal with an external process
> > which we're *sure* won't be generating any output on stdout/stderr
[quoted text clipped - 14 lines]
> each of them, and if you fail to close them you will run out
> eventually.

Thanks a lot for the infos.  I'm working on it at the moment.

Tristan


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.