Changeset: 7c5731c2d7b5 for MonetDB
URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=7c5731c2d7b5
Modified Files:
monetdb5/mal/mal_session.mx
Branch: headless
Log Message:
Prepare mal_session for split
diffs (299 lines):
diff --git a/monetdb5/mal/mal_session.mx b/monetdb5/mal/mal_session.mx
--- a/monetdb5/mal/mal_session.mx
+++ b/monetdb5/mal/mal_session.mx
@@ -17,20 +17,6 @@
All Rights Reserved.
@
-@a M. Kersten
-@v 0.0
-@- Server Bootstrapping
-
-The MonetDB server uses a startup script to boot the system.
-This script is an ordinary MAL program, but will mostly
-consist of include statements to load modules of general interest.
-The startup script is ran as user Admin.
-Its location is described in Monet configuration file.
-The default location is: !!!%%% TODO %%%!!! <-- FIXME
-
-It may overwritten using a command line argument.
-
-@{
@h
#ifndef _MAL_SESSION_H
#define _MAL_SESSION_H
@@ -55,6 +41,14 @@
#endif /* _MAL_SESSION_H */
@c
+/* Author(s) M.L. Kersten
+ * Server Bootstrapping
+ * The MonetDB server uses a startup script to boot the system.
+ * This script is an ordinary MAL program, but will mostly
+ * consist of include statements to load modules of general interest.
+ * The startup script is ran as user monetdb.
+*/
+
#include "monetdb_config.h"
#include "mal_session.h"
#include "mal_instruction.h" /* for pushEndInstruction() */
@@ -81,7 +75,7 @@
return 0;
}
MSinitClientPrg(c, "user", "main");
- (void)MCinitClientThread(c);
+ (void) MCinitClientThread(c);
s = malInclude(c, bootfile, 0);
if (s != NULL) {
mnstr_printf(GDKout, "!%s\n", s);
@@ -98,22 +92,22 @@
return 1;
}
-@+ Client main routine
-Every client has a 'main' function to collect the statements.
-Once the END instruction has been found, it is added to the
-symbol table and a fresh container is being constructed.
-Note, this scheme makes testing for recursive function calls a
-little more difficult. Therefore, type checking should be performed
-afterwards.
-
-In interactive mode, the closing statement is never reached.
-The 'main' procedure is typically cleaned between successive external
-messages except for its variables, which are considerd global.
-This storage container is re-used when during the previous call
-nothing was added.
-At the end of the session we have to garbage collect the BATs
-introduced.
-@c
+/* Client main routine
+ * Every client has a 'main' function to collect the statements.
+ * Once the END instruction has been found, it is added to the
+ * symbol table and a fresh container is being constructed.
+ * Note, this scheme makes testing for recursive function calls a
+ * little more difficult. Therefore, type checking should be performed
+ * afterwards.
+ *
+ * In interactive mode, the closing statement is never reached.
+ * The 'main' procedure is typically cleaned between successive external
+ * messages except for its variables, which are considerd global.
+ * This storage container is re-used when during the previous call
+ * nothing was added.
+ * At the end of the session we have to garbage collect the BATs
+ * introduced.
+*/
void
MSinitClientPrg(Client cntxt, str mod, str nme)
@@ -124,25 +118,6 @@
if (cntxt->curprg && idcmp(nme, cntxt->curprg->name) == 0) {
MSresetClientPrg(cntxt);
return;
-/*
- int i, cnt = 1;
- mb = cntxt->curprg->def;
- cntxt->itrace = 0;
- getInstrPtr(mb,0)->gc = 0;
- for (i = 1; i < mb->stop; i++)
- if (mb->stmt[i]->token == REMsymbol)
- cnt++;
- if (mb->stop <= cnt + 1) {
- mb->typefixed = 0;
- mb->flowfixed = 0;
- mb->stop = cnt;
- return;
- }
- if( mb->history){
- freeMalBlk(mb->history);
- mb->history=0;
- }
-*/
}
cntxt->curprg = newFunction(putName("user",4), putName(nme,
strlen(nme)), FUNCTIONsymbol);
mb = cntxt->curprg->def;
@@ -182,16 +157,15 @@
}
}
-@}
-@+ Client authorization
-The default method to interact with the database server is to
-connect using a port number. The first line received should contain
-authorization information, such as user name.
+/* Client authorization
+ * The default method to interact with the database server is to
+ * connect using a port number. The first line received should contain
+ * authorization information, such as user name.
+ *
+ * The scheduleClient receives a challenge response consisting of
+ * endian:user:password:lang:database:
+*/
-@{
-The scheduleClient receives a challenge response consisting of
-endian:user:password:lang:database:
-@c
void
MSscheduleClient(str command, str challenge, bstream *fin, stream *fout)
{
@@ -370,28 +344,28 @@
}
}
-@+ Client services
-After the client initialization has been finished, we
-can start the interaction protocol. This involves parsing the
-input in the context of an already defined procedure and upon
-success, its execution.
-
-In essence, this calls for an incremental parsing operation,
-because we should wait until a complete basic block has been detected.
-Test, first collect the instructions before we take them all.
-@-
-In interactive mode, we should remove the instructions before
-accepting new ones. The function signature remains the same
-and the symbol table should also not be affected.
-Aside from removing instruction, we should also condense the
-variable stack, i.e. removing at least the temporary variables,
-but maybe everything beyond a previous defined pont.
-
-Beware that we have to cleanup the global stack as well. This to avoid
-subsequent calls to find garbage information.
-However, this action is only required after a successful execution.
-Otherwise, garbage collection is not needed.
-@c
+/* Client services
+ * After the client initialization has been finished, we
+ * can start the interaction protocol. This involves parsing the
+ * input in the context of an already defined procedure and upon
+ * success, its execution.
+ *
+ * In essence, this calls for an incremental parsing operation,
+ * because we should wait until a complete basic block has been detected.
+ * Test, first collect the instructions before we take them all.
+ *
+ * In interactive mode, we should remove the instructions before
+ * accepting new ones. The function signature remains the same
+ * and the symbol table should also not be affected.
+ * Aside from removing instruction, we should also condense the
+ * variable stack, i.e. removing at least the temporary variables,
+ * but maybe everything beyond a previous defined pont.
+ *
+ * Beware that we have to cleanup the global stack as well. This to avoid
+ * subsequent calls to find garbage information.
+ * However, this action is only required after a successful execution.
+ * Otherwise, garbage collection is not needed.
+*/
void
MSresetInstructions(MalBlkPtr mb, int start)
{
@@ -407,9 +381,7 @@
mb->stop = start;
}
-@-
-Determine the variable being used and clear non-used onces.
-@c
+/* Determine the variable being used and clear non-used onces. */
void
MSresetVariables(Client cntxt, MalBlkPtr mb, MalStkPtr glb, int start)
{
@@ -442,12 +414,13 @@
GDKfree(used);
}
-@-
-Here we start the first client. We need to initialize
-the corresponding thread and allocate space for the
-global variables. Thereafter it is up to the scenario
-interpreter to process input.
-@c
+/*
+ * Here we start the first client. We need to initialize
+ * the corresponding thread and allocate space for the
+ * global variables. Thereafter it is up to the scenario
+ * interpreter to process input.
+*/
+
void
MSserveClient(void *dummy)
{
@@ -459,10 +432,10 @@
MCcloseClient(c);
return;
}
-@-
-A stack frame is initialized to keep track of global variables.
-The scenarios are run until we finally close the last one.
-@c
+/*
+ * A stack frame is initialized to keep track of global variables.
+ * The scenarios are run until we finally close the last one.
+*/
mb = c->curprg->def;
if ( c->glb == NULL)
newStack(c->glb,STACKINCR + mb->vsize);
@@ -493,9 +466,7 @@
#endif
} while(c->scenario && c->mode != FINISHING);
}
-@-
-At this stage we should clean out the MAL block
-@c
+ /* At this stage we should clean out the MAL block */
freeMalBlk(c->curprg->def);
c->curprg->def = 0;
@@ -510,18 +481,18 @@
MCcloseClient(c);
}
-@+ MAL scenario components
-The stages of processing user requests are controlled by a
-scenario. The routines below are the default implementation.
-The main issues to deal after parsing it to clean out the
-Admin.main function from any information added erroneously.
+/* MAL scenario components
+ * The stages of processing user requests are controlled by a
+ * scenario. The routines below are the default implementation.
+ * The main issues to deal after parsing it to clean out the
+ * Admin.main function from any information added erroneously.
+ *
+ * Ideally this involves resetting the state of the client
+ * 'main' function, i.e. the symbol table is reset and any
+ * instruction added should be cleaned. Beware that the instruction
+ * table may have grown in size.
+*/
-Ideally this involves resetting the state of the client
-'main' function, i.e. the symbol table is reset and any
-instruction added should be cleaned. Beware that the instruction
-table may have grown in size.
-
-@c
str
MALinitClient(Client c)
{
@@ -666,11 +637,11 @@
if (c->listing > 1 )
printFunction(c->fdout, c->curprg->def, 0, c->listing);
-@-
-In interactive mode we should avoid early garbage collection of values.
-This can be controlled by the clean up control at the instruction level
-and marking all non-temporary variables as being (potentially) used.
-@c
+/*
+ * In interactive mode we should avoid early garbage collection of values.
+ * This can be controlled by the clean up control at the instruction level
+ * and marking all non-temporary variables as being (potentially) used.
+*/
if (c->glb){
c->glb->pcup = 0;
c->glb->keepAlive= TRUE; /* no garbage collection */
@@ -700,5 +671,3 @@
mnstr_printf(c->fdout,"mdb>#EOD\n");
return msg;
}
-
-@}
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
