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

Andrew Haley aph@redhat.com
Wed Jul 14 17:20:00 GMT 2004


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.


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /