thread does not return from Runtime.exec
-
Hi, I'm new to using Runtime.getRuntime().exec on WindowsXP, JRE 6. Solution should work on all Windows NT from 5 upwards and common UNIX. I called it in the following way process = Runtime.getRuntime().exec(cmdargs); where cmdargs[0] = "D:\Somepath\NmMutex" cmdargs[1] = "lock" Program NmMutex with argument lock runs until its process is stopped externally. When Runtime.getRuntime().exec(cmdargs); is called, the calling thread remains suspended, until program NmMutex is killed. Is that the normal behaviour of Runtime.exec? I thought the calling thread would return, even if the program it started is still running, so I can observe the prog by reading its stdout and stderr from my Java app. If not it would return there would be no process created and I could not observe the program. Which way is best to solve that? Start prog in Background, like process = Runtime.getRuntime().exec("start /B NmMutex lock"); resp. process = Runtime.getRuntime().exec("& NmMutex lock"); ? Thank you Werner
-
Hi, I'm new to using Runtime.getRuntime().exec on WindowsXP, JRE 6. Solution should work on all Windows NT from 5 upwards and common UNIX. I called it in the following way process = Runtime.getRuntime().exec(cmdargs); where cmdargs[0] = "D:\Somepath\NmMutex" cmdargs[1] = "lock" Program NmMutex with argument lock runs until its process is stopped externally. When Runtime.getRuntime().exec(cmdargs); is called, the calling thread remains suspended, until program NmMutex is killed. Is that the normal behaviour of Runtime.exec? I thought the calling thread would return, even if the program it started is still running, so I can observe the prog by reading its stdout and stderr from my Java app. If not it would return there would be no process created and I could not observe the program. Which way is best to solve that? Start prog in Background, like process = Runtime.getRuntime().exec("start /B NmMutex lock"); resp. process = Runtime.getRuntime().exec("& NmMutex lock"); ? Thank you Werner
It looks like Runtime.exec() is blocking on the process it spawned (like the old Unix exec()?). I can think of two portable solutions: 1. start a new Thread to do the exec() and let it block. 2. use ProcessBuilder.start()[^] This article[^] discusses the use of ProcessBuilder and Runtime. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
It looks like Runtime.exec() is blocking on the process it spawned (like the old Unix exec()?). I can think of two portable solutions: 1. start a new Thread to do the exec() and let it block. 2. use ProcessBuilder.start()[^] This article[^] discusses the use of ProcessBuilder and Runtime. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
It looks like that, although I'm much surprised, because this is not what Runtime.exec should do, when I read into the docs - ehm - assumed I understood them also. 1 might work, but you don't get the process handle, because calling thread is suspended before return from call 2 yes right, I think its worth trying because it seems to be more convenient thank you Werner
-
It looks like that, although I'm much surprised, because this is not what Runtime.exec should do, when I read into the docs - ehm - assumed I understood them also. 1 might work, but you don't get the process handle, because calling thread is suspended before return from call 2 yes right, I think its worth trying because it seems to be more convenient thank you Werner
I couldn't see anywhere the blocking/non-blocking behaviour of exec() was specified. I think I read somewhere that ProcessBuilder is the preferred technology since Java 5. Certainly looks a lot more usable, although I haven't used either in anger. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
I couldn't see anywhere the blocking/non-blocking behaviour of exec() was specified. I think I read somewhere that ProcessBuilder is the preferred technology since Java 5. Certainly looks a lot more usable, although I haven't used either in anger. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
Hi, I tried the same with process builder
ProcessBuilder pbuilder = new ProcessBuilder(cmdlist); process = pbuilder.start(); procmon = new ProcessMonitor(process);where cmdlist[0] = "D:/MyPath/NmMutex" cmdlist[1] = "lock" (btw. this doesn't mean the main thread waits at lock, its try_lock) The thread returns as soon as the process, which was called ended. I tested it with a loop whithin the external process. If it is finite, the thread returns. If it is infinite the thread doesn't return. I.e. exec and start are blocking. The idea to call ProcessBuilder.start within a separate process is basically good, but I woudn't receive a process handle when start would not return. And without that, I would not be able to attach streams to the stdout and stderr. Hence the process might block as soon as the stdout and stderr buffers are filled up. If I started a background shell and within that my process, the solution would be os dependend (not KISS, complicated, not that good). Thanks Werner
-
I couldn't see anywhere the blocking/non-blocking behaviour of exec() was specified. I think I read somewhere that ProcessBuilder is the preferred technology since Java 5. Certainly looks a lot more usable, although I haven't used either in anger. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
Hi, the process started by ProcessBuilder and by Runtime.exec - which is implemented via ProcessBuilder - is started asynchronously when the java app is started from jar. The effect of the frozen thread happened exclusively within the debbuger session. I should have tried. Sorry and thanks again Werner