mal_scenario.mx

一个内存数据库的源代码这是服务器端还有客户端

@' The contents of this file are subject to the MonetDB Public License
@' Version 1.1 (the "License"); you may not use this file except in
@' compliance with the License. You may obtain a copy of the License at
@' http://monetdb.cwi.nl/Legal/MonetDBLicense-1.1.html
@'
@' Software distributed under the License is distributed on an "AS IS"
@' basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
@' License for the specific language governing rights and limitations
@' under the License.
@'
@' The Original Code is the MonetDB Database System.
@'
@' The Initial Developer of the Original Code is CWI.
@' Portions created by CWI are Copyright (C) 1997-2007 CWI.
@' All Rights Reserved.

@f mal_scenario
@a M. Kersten
@v 0.0
@+ Session Scenarios
In MonetDB multiple languages, optimizers, and execution engines can
be combined at run time to satisfy a wide user-community.
Such an assemblage of components is called a @emph{scenario}
and consists of a @emph{reader}, @emph{parser}, @emph{optimizer},
@emph{tactic scheduler} and @emph{engine}. These hooks allow
for both linked-in and external components.

The languages supported are SQL, XQuery, 
and the Monet Assembly Language (MAL).
The default scenario handles MAL instructions, which is used
to illustrate the behavior of the scenario steps.

The MAL reader component handles interaction with
a front-end to obtain a string for subsequent compilation and
execution. The reader uses the common stream package to read
data in large chunks, if possible. In interactive mode the lines
are processed one at a time. 

The MAL parser component turns the string into
an internal representation of the MAL program. 
During this phase semantic checks are performed, such that
we end up with a type correct program.

The code block is subsequently sent to an MAL optimizer.
In the default case the program is left untouched. For other languages, 
the optimizer deploys language specific code transformations,
e.g. foreign-key optimizations in joins and remote query execution.
All optimization information is statically derived from the
code blocks and possible catalogues maintained for the query language
at hand. Optimizers leave advice and their findings in properties
in the symbol table, see @ref{Property Management}.

Once the program has thus been refined, the
MAL scheduler prepares for execution using tactical optimizations.
For example, it may parallelize the code, generate an ad-hoc
user-defined function, or prepare for efficient replication management.
In the default case, the program is handed over to the MAL interpreter
without any further modification.

The final stage is to choose an execution paradigm,
i.e. interpretative (default), compilation of an ad-hoc user
defined function, dataflow driven interpretation,
or vectorized pipe-line execution by a dedicated engine.

A failure encountered in any of the steps terminates the scenario
cycle. It returns to the user for a new command.

@+ Scenario management
Scenarios are captured in modules; they can be dynamically loaded
and remain active until the system is brought to a halt.
The first time a scenario @sc{xyz} is used, the system looks for a scenario
initialization routine @sc{xyzinitSystem()} and executes it. 
It is typically used to prepare the server for language specific interactions.
Thereafter its components are set to those required by
the scenario and the client initialization takes place.

When the last user interested in a particular scenario leaves the
scene, we activate its finalization routine calling @sc{xyzexitSystem()}.
It typically perform cleanup, backup and monitoring functions.

A scenario is interpreted in a strictly linear fashion,
i.e. performing a symbolic optimization before scheduling decisions
are taken.
The routines associated with each state in
the scenario may patch the code so as to assure that subsequent
execution can use a different scenario, e.g. to handle dynamic
code fragments.

@{
The state of execution is maintained in the scenario record for
each individual client. Sharing this information between clients
should be dealt with in the implementation of the scenario managers.
Upon need, the client can postpone a session scenario by 
pushing a new one(language, optimize, tactic, 
processor). Propagation of the state information is
encapsulated a scenario2scenario() call. Not all transformations
may be legal.

@+ Scenario administration
Administration of scenarios follows the access rules 
defined for code modules in general.

@h

#ifndef _MAL_SCENARIO_H
#define _MAL_SCENARIO_H

#include "mal_import.h"

#define READER 0
#define PARSER  1
#define OPTIMIZE 2
#define SCHEDULER 3
#define ENGINE 4
#define INITCLIENT 5
#define EXITCLIENT 6

/*#define MAL_SCENARIO_DEBUG*/
@-
The scenario descriptions contains all information to
implement the scenario. Each client gets a copy.
An exception or error detected while parsing is turned
into an exception and aborts the scenario.
@h
#define MAXSCEN 128

typedef struct SCENARIO {
	str name, language;
	str initSystem;
	MALfcn initSystemCmd;
	str exitSystem;
	MALfcn exitSystemCmd;
	str initClient;
	MALfcn initClientCmd;
	str exitClient;
	MALfcn exitClientCmd;
	str reader;
	MALfcn readerCmd;
	void *readerState;
	str parser;
	MALfcn parserCmd;
	void *parserState;
	str optimizer;
	MALfcn optimizerCmd;
	void *optimizerState;
	str tactics;
	MALfcn tacticsCmd;
	void *tacticsState;
	str engine;
	MALfcn engineCmd;
	void *engineState;
	struct SCENARIO *next;
} *Scenario;

mal_export str setScenario(Client c, str nme);
mal_export str runScenario(Client c);
mal_export str runScenarioBody(Client c);
mal_export str fillScenario(Client c, Scenario scen);
mal_export void clrScenario(Client c);
mal_export str getScenarioLanguage(Client c);
mal_export Scenario getFreeScenario(void);

mal_export str defaultScenario(Client c);	/* used in src/mal/mal_session.c */
mal_export void exitScenario(Client c);	/* used in src/mal/mal_session.c */
mal_export str initScenario(Client c, Scenario s);

mal_export void showCurrentScenario(void);
mal_export void showScenarioByName(stream *f, str s);
mal_export void showScenario(stream *f, Scenario s);
mal_export void showAllScenarios(stream *f);
mal_export void resetScenario(Client c);

mal_export Scenario findScenario(str nme);
mal_export void updateScenario(str nme, MALfcn fcn);

#endif /* _MAL_SCENARIO_H */
@-
@c
#include "mal_config.h"
#include "mal_scenario.h"
#include "mal_linker.h"		/* for getAddress() */
#include "mal_client.h"
#include "mal_authorize.h"
#include "mal_exception.h"

struct SCENARIO scenarioRec[MAXSCEN] = {
	{"mal", "mal",
	 0, 0,			/* hardwired MALinit*/
	 0, 0,			/* implicit */
	 0, 0,			/* no initClient */
	 "MALexitClient", (MALfcn) &MALexitClient,
	 "MALreader", (MALfcn) &MALreader, 0,
	 "MALparser", (MALfcn) &MALparser, 0,
	 "MALoptimizer", 0, 0,			
	 0, 0, 0,
	 "MALengine", (MALfcn) &MALengine, 0, 0},
	{0,0,			/* name */
	 0, 0,			/* init */
	 0, 0,			/* exit */
	 0, 0,			/* initClient */
	 0, 0,			/* exitClient */
	 0, 0, 0,		/* reader */
	 0, 0, 0,		/* parser */
	 0, 0, 0,		/* optimizer */
	 0, 0, 0,		/* scheduler */
	 0, 0, 0, 0		/* engine */
	 }
};

@-
Currently each user can define a new scenario, provided we have a free slot.
Scenarios not hardwired can always be dropped.
@c
Scenario
getFreeScenario()
{
	int i;
	Scenario scen = NULL;

	mal_set_lock(mal_contextLock, "Scenario");
	for (i = 0; i < MAXSCEN && scenarioRec[i].name; i++)
		;

	if (i == MAXSCEN) {
		showException(MAL,"freeScenario", "no scenario space left (%d); adjust MAXSCEN and recompile", MAXSCEN);
	} else {
		scen = scenarioRec + i;
	}
	mal_unset_lock(mal_contextLock, "Scenario");

	return scen;
}

@-
@= initScen
if( @1->@2){
	if( @1->@2Cmd == 0) @1->@2Cmd = (MALfcn)getAddress(@3,@3,@1->@2,1);
}
@-
A scenario is initialized only once per session. 
All other requests are silently ignored. 
After initialization, all state functions should have been set.
Initialization includes searching for the scenario startup file in
the etc/MonetDB directory. This creates a dependency, because the
malInclude also needs a scenario. To break this cycle, the system should
call once the routine default scenario for each client first.
@c
str
initScenario(Client c, Scenario s)
{
	str msg = MAL_SUCCEED;

	if (s->initSystemCmd)
		return(fillScenario(c, s));
	/* prepare for conclicts */
	mal_set_lock(mal_contextLock, "Scenario");
	if (s->initSystem && s->initSystemCmd == 0) {
		s->initSystemCmd = (MALfcn) getAddress(s->language, s->language, s->initSystem,1);
		if (s->initSystemCmd) {
			msg = (*s->initSystemCmd) (c);
		} else {
			char buf[BUFSIZ];
			snprintf(buf,BUFSIZ,"%s.init",s->language);
			msg = createException(MAL, buf, "Scenario not initialized"); 
		}
	}
	/* does the return below unset the lock? */
	if (msg)
		return msg;
	@:initScen(s, exitSystem,s->language)@
	@:initScen(s, initClient,s->language)@
	@:initScen(s, exitClient,s->language)@
	@:initScen(s, reader,s->language)@
	@:initScen(s, parser,s->language)@
	@:initScen(s, optimizer,s->language)@
	@:initScen(s, tactics,s->language)@
	@:initScen(s, engine,s->language)@
	mal_unset_lock(mal_contextLock, "Scenario");
	return(fillScenario(c, s));
}

str
defaultScenario(Client c)
{
	return initScenario(c, scenarioRec);
}

@-
The Monet debugger provides an option to inspect the scenarios currently
defined.
@= scenarioCommand
    if( scen->@1) stream_printf(f," \"%s%s\",",scen->@1,
        (scen->@1Cmd?"":"?"));
    else stream_printf(f," nil,");
@c
void
showScenario(stream *f, Scenario scen)
{
	stream_printf(f, "[ \"%s\",", scen->name);
	@:scenarioCommand(initSystem)@
	@:scenarioCommand(exitSystem)@
	@:scenarioCommand(initClient)@
	@:scenarioCommand(exitClient)@
	@:scenarioCommand(parser)@
	@:scenarioCommand(optimizer)@
	@:scenarioCommand(tactics)@
	@:scenarioCommand(engine)@
	stream_printf(f, "]\n");
}

Scenario
findScenario(str nme)
{
	int i;
	Scenario scen = scenarioRec;