/*______________________________________________________________________________
 * 
 * org.eidola.kernel.Engine
 * 
 * Part of the Eidola Kernel Reference Implementation
 * See http://eidola.org for oodles of relevant fun!
 * 
 *______________________________________________________________________________
 * 
 * Copyright 2000-2001 Paul Cantrell
 * 
 * This program is free software; you can redistribute it and/or modify it under
 * the terms of the GNU General Public License version 2, as published by the
 * Free Software Foundation. See the file LICENSE.html for more information.
 * 
 * This program is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY, including the implied warranty of MERCHANTABILITY or FITNESS
 * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License along with
 * this program; if not, write to the Free Software Foundation, Inc. / 59 Temple
 * Place, Suite 330 / Boston, MA 02111-1307 / USA.
 *_______________________________________________________________________________
 */

package org.eidola.kernel;

import org.eidola.kernel.event.*;
import org.eidola.util.ThreadFlock;

/**
	Responsible for the large-scale organization of containers.
	This class is just a sketch until it becomes clearer exactly what
	sort of "large-scale organization" needs to happen, and which
	responsibilities fall on the UI vs. the kernel.
	Containers take an engine as a constructor argument, and add
	themselves on creation.  This will almost certainly change.
	<p>
	Currently, the Engine does two things:
	<ul>
		<li> It runs a flock of threads running a {@link Compiler}.
		<li> It creates a queue for propagating events between containers.
	</ul>
	<p>
	Open questions include:
	<ul>
		<li> Should the engine provide an interface for tracking all
			containers created?  Should it provide a global name-based lookup?
		<li> Is it wise to have containers add themselves on creation?
			There may well be situations where we want to futz with a new
			container without having somebody trying to compile it.
		<li> Is it wise to have a default static instance that everybody
			shares?  It might be better to allow multiple engines in the same
			JVM for doing things like developing/debugging Eidola in Eidola
			(not that this will be a question in the immediate future).
		<li> Is it better to make Namespace responsible for tracking
			containers' names, attaching them to an engine, and so forth?
			This might be the way to go, but the requirements aren't clear yet.
	</ul>
	
	@author Paul Cantrell
	@version [Development version]
*/

public class Engine
	{
	static public Engine getInstance()
		{
		if(defaultInstance == null)
			synchronized(Engine.class)
				{
				if(defaultInstance == null)
					(defaultInstance = new Engine()).start();
				}
		return defaultInstance;
		}
	
	static private Engine defaultInstance;
	
	private Engine()
		{
		compiler = new Compiler();
		compilerQ = new EventQueue("compilerQ");
		compilerFlock = new ThreadFlock(compilerQ, 3);
		compilerFlock.setPriority(Thread.NORM_PRIORITY-2);
		compilerFlock.setDaemon(true);
		
		propagatorQ = new EventQueue("propagatorQ");
		propagatorFlock = new ThreadFlock(propagatorQ, 3);
		propagatorFlock.setPriority(Thread.NORM_PRIORITY-1);
		propagatorFlock.setDaemon(true);
		}
	
	public void start()
		{
		compilerFlock.start();
		propagatorFlock.start();
		}
	
	public void add(Container container)
		{ container.addListener(compiler, compilerQ); }
	
	public void remove(Container container)
		{ container.removeListener(compiler); }
	
	public EventQueue getPropagatorQ()
		{ return propagatorQ; }
	
	private Compiler    compiler;
	private EventQueue  compilerQ;
	private ThreadFlock compilerFlock;
	
	private EventQueue  propagatorQ;
	private ThreadFlock propagatorFlock;
	}