Changeset: d69b0e5ebf74 for MonetDB
URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=d69b0e5ebf74
Modified Files:
monetdb5/mal/mal_scenario.mx
Branch: headless
Log Message:
mal_session prepared for split
diffs (truncated from 422 to 300 lines):
diff --git a/monetdb5/mal/mal_scenario.mx b/monetdb5/mal/mal_scenario.mx
--- a/monetdb5/mal/mal_scenario.mx
+++ b/monetdb5/mal/mal_scenario.mx
@@ -16,93 +16,6 @@
Copyright August 2008-2011 MonetDB B.V.
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
@@ -178,6 +91,86 @@
#endif /* _MAL_SCENARIO_H */
@-
@c
+/* Author(s) M.L. Kersten
+ * 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 currently is SQL,
+ * 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.
+*/
+
#include "monetdb_config.h"
#include "mal_scenario.h"
#include "mal_linker.h" /* for getAddress() */
@@ -185,10 +178,6 @@
#include "mal_authorize.h"
#include "mal_exception.h"
-#ifdef HAVE_SYS_TIMES_H
-# include <sys/times.h>
-#endif
-
struct SCENARIO scenarioRec[MAXSCEN] = {
{"mal", "mal",
0, 0, /* hardwired MALinit*/
@@ -213,10 +202,11 @@
}
};
-@-
-Currently each user can define a new scenario, provided we have a free slot.
-Scenarios not hardwired can always be dropped.
-@c
+/*
+ * Currently each user can define a new scenario, provided we have a free slot.
+ * Scenarios not hardwired can always be dropped.
+*/
+
Scenario
getFreeScenario()
{
@@ -237,15 +227,15 @@
return scen;
}
-@-
-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
+/* 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.
+*/
+
str
initScenario(Client c, Scenario s)
{
@@ -297,11 +287,8 @@
return initScenario(c, scenarioRec);
}
-@-
-The Monet debugger provides an option to inspect the scenarios currently
-defined.
+/* The Monet debugger provides an option to inspect the scenarios currently
defined. */
-@c
static void
print_scenarioCommand(stream *f, str cmd, MALfcn funcptr)
{
@@ -338,13 +325,13 @@
return NULL;
}
-@-
-Functions may become resolved only after the corresponding module
-has been loaded. This should be announced as part of the module
-prelude code.
-Beware that after the update, we also have to adjust the client records.
-They contain a copy of the functions addresses.
-@c
+/* Functions may become resolved only after the corresponding module
+ * has been loaded. This should be announced as part of the module
+ * prelude code.
+ * Beware that after the update, we also have to adjust the client records.
+ * They contain a copy of the functions addresses.
+*/
+
void
updateScenario(str nme, str fnme, MALfcn fcn)
{
@@ -420,20 +407,20 @@
if( scen) return scen->language;
return "mal";
}
-@-
-Changing the scenario for a particular client invalidates the
-state maintained for the previous scenario. The old scenario is
-retained in the client record to facilitate propagation of
-state information, or to simply switch back to the previous one.
-Before we initialize a scenario the client scenario is reset to
-the MAL scenario. This implies that all scenarios are initialized
-using the same scenario. After the scenario initialization file
-has been processed, the scenario phases are replaced with the
-proper ones.
-@-
-All client records should be initialized with a default
-scenario, i.e. the first described in the scenario table.
+/* Changing the scenario for a particular client invalidates the
+ * state maintained for the previous scenario. The old scenario is
+ * retained in the client record to facilitate propagation of
+ * state information, or to simply switch back to the previous one.
+ * Before we initialize a scenario the client scenario is reset to
+ * the MAL scenario. This implies that all scenarios are initialized
+ * using the same scenario. After the scenario initialization file
+ * has been processed, the scenario phases are replaced with the
+ * proper ones.
+ * All client records should be initialized with a default
+ * scenario, i.e. the first described in the scenario table.
+*/
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
