OpenXM/doc/issac2000/session-management.tex - diff

Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / issac2000

Diff for /OpenXM/doc/issac2000/session-management.tex between version 1.6 and 1.7

version 1.6, 2000/01/15 00:20:46

version 1.7, 2000/01/15 03:46:27

Line 1

% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.5 2000/01/11 05:35:48 noro Exp $

% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.6 2000/01/15 00:20:46 takayama Exp $

\section{Session Management}

\label{secsession}

Line 23 messages. As the streams are for binary data,

the byte order conversion is necessary when a

client and a server have different byte orders. It is determined by

exchanging the preferable byte order of each peer. If the preference

does not coincides with each other,

does not coincide with each other,

then the network byte order is used.

This implies that all servers and clients should be able to

handle the network byte

Line 50 specified port number.

setting the binary I/O channels appropriately.

\end{enumerate}

Though the above is all the task as a launcher, the launcher process

After finishing the above task as a launcher, the launcher process

acts as a control server and controls the server process created by

itself. As for a control server see Section \ref{control}.

Line 59 itself. As for a control server see Section \ref{contr

When we use a mathematical software, an execution time or necessary

storage is often unknown in advance. Therefore it is desirable

to be able to abort an execution and to start another execution.

On OpenXM we adopted the following simple and robust method.

In OpenXM we adopted the following simple and robust method.

An OpenXM server has logically two I/O channels: one for exchanging

data for computations and the other for controlling computations. The

Line 104 a resetting.

\begin{enumerate}

\item The client sends {\tt SM\_control\_reset\_connection} to the

control server.

control server. The control server sends {\tt SIGUSR1} to the engine.

\item The client enters the resetting state. it skips all {\tt

OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.

\item After receiving {\tt OX\_SYNC\_BALL} the client sends

Line 128 usual state.

\end{enumerate}

{\tt OX\_SYNC\_BALL} means an end mark of the data remaining in the

I/O streams. After reading it it is assured that the stream is empty

I/O streams. After reading it it is assured that each stream is empty

and that a request from a client correctly corresponds to the response

and that the subsequent request from a client correctly

from the server. We note that we don't have to associate

corresponds to the response from the server.

{\tt OX\_SYNC\_BALL} with

We note that we don't have to associate {\tt OX\_SYNC\_BALL} with

any special action to be executed by the server because it is

assured that the peer is in the resetting state when one receives

{\tt OX\_SYNC\_BALL}.

Line 146 then debugging of user defined programs will be

possible. For example {\tt ox\_asir}, which is

the OpenXM server of {\tt Risa/Asir}, can pop up a window to input

debug commands and the debugging similar to that on usual terminals is possible.

One can also send {\tt SIGINT} by using {\tt SM\_control\_intr}

One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}

and it provides a similar functionality to entering the debugging

mode from a keyboard interruption.

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>