I have a (Java) process which is staring a separate process foo. foo takes some number of seconds to start up, then is really running. Control returns back to the parent process as soon as foo is started, but not necessarily ready.

Note also that foo writes human-readable output to both stdout and, in debug mode, stderr.

The options I'm aware of:

  1. sleep the parent process for n seconds, where n is theoretically larger than foo will ever take.
  2. Have the parent process looking for something special in the child's stdout or stderr, and block until it's seen.
  3. Touch some sort of marker file in the OS when foo is ready, and have the parent process watch that file.

I don't really like any of these options (1. has a race condition, 2. involves matching magic strings, and 3. risks multiple foo processes colliding). Going the other way (parent to child) I could send a signal to communicate, but I'm not aware of a better way for the child process to communicate its state to the parent.

  • 1
    I've voted to close this as too broad since IPC is an extensively documented realm with many possibilities (semaphores, pipes, signals, etc), of which you seem to be mostly unaware. But now you know what it is called, you can do some research and if there's any confusion come back with a more specific question (or ask it on Stack Overflow, which is probably more appropriate for cross-platform Java). BTW, I intentionally emphasized signals, although they are a little less cross-platform. – goldilocks Jul 1 '15 at 18:49
  • @goldilocks agreed, there are numerous ways to IPC. I'm curious specifically what is a robust way for a process to indicate it's "ready", since control returning to the parent process isn't sufficient. – dimo414 Jul 1 '15 at 20:12
  • In a unix context signals are ideal, but Java throws a bit of a wrench into that...so if both processes are JVM processes, once again this is really a Java question. Your concern about "magic strings" WRT #2 is misplaced -- this makes any and all communication protocols, including IP, TCP, HTTP, etc. a bad practice since protocols do mean hardcoded formats. There is no way around that, which is why there are protocol specifications. By analogy, is speaking in a particular human language a bad "magic string" based practice? What are the alternatives? – goldilocks Jul 1 '15 at 20:27
  • @goldilocks My Java process is starting a non-JVM process. My issue with "magic strings" is that the child process currently prints something like Program is now running... but there's nothing stopping the developer of the child process from changing that; the output is for users, it's not documented behavior. On the other hand, it is documented to listen for SIGHUP and SIGINT to terminate. We could explore making some string of text in its output part of its documented API, but that isn't the case today. I'm looking for SIGINT-like behavior the child can send to the parent. – dimo414 Jul 1 '15 at 20:50
  • 1
    This is a programming question and belongs on Stack Overflow. The most natural method is for the parent to open a pipe and for the child to write a byte to it or close it. – Gilles 'SO- stop being evil' Jul 1 '15 at 22:21

The child could send a signal to the parent. SIGUSR1 and SIGUSR2 exist for this kind of ad hoc situation and could be ideal here.

Your application can find its parent's process id easily enough with the Java equivalent of getppid(), or as an alternative perhaps you could have the parent pass its own PID ($$) on the command line as an argument that your Java code could pick up.

| improve this answer | |
  • This is exactly what I was driving at. I don't think Java has standard facilities for sending signals, but it has some for handling them. Unfortunately it doesn't look like getting the process ID is so simple either...so this vs. a pipe is sort of a matter of what style of "robustness" is required. – goldilocks Jul 2 '15 at 11:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.