Re: [RFC] Fix PosixProcess by porting VMProcess from Classpath...

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Andrew Haley wrote:
 > > I'd be interested to know if Classpath's
 > > implementation of Process is stable and if anyone has ever used it for
 > > anything much.  Forewarned is forearmed, as they say.
 > 
 > One thing I don't like about Classpath's VMProcess is that it polls for
 > terminated processes.

Rather than using SIGCHLD, you mean?  Hmm.

     // Max time (in ms) we'll delay before trying to reap another child.
     private static final int MAX_REAP_DELAY = 1000;

    ...

	  // If there are more new processes to create, go do that now.
	  // If there is nothing left to do, exit this thread. Otherwise,
	  // sleep a little while, and then check again for reapable children.
	  // We will get woken up immediately if there are new processes to
	  // spawn, but not if there are new children to reap. So we only
	  // sleep a short time, in effect polling while processes are active.
	  synchronized (workList)
	    {
	      if (!workList.isEmpty())
		continue;
	      if (activeMap.isEmpty())
		{
		  processThread = null;
		  break;
		}
	
	      try
		{
		  workList.wait(MAX_REAP_DELAY);
		}
	      catch (InterruptedException e)
		{
		  /* ignore */
		}
	    }

So, we wait either to be notified or until one second has passed.
That doesn't seem like such a great scheme, altho' it's better than
what we do at present.  

I suppose the right thing to do is call wait(2) instead of waiting on
workList -- when we add a process to that list we can send the
reaper/initiator thread a signal to wake it up.

Andrew.