scsh-checkins
[Top] [All Lists]

 Update of /cvsroot/scsh/scsh-0.6/doc/scsh-manual In directory usw-pr-cvs1:/tmp/cvs-serv15949/doc/scsh-manual Modified Files: threads.tex Log Message: Documentation for the rest. Index: threads.tex =================================================================== RCS file: /cvsroot/scsh/scsh-0.6/doc/scsh-manual/threads.tex,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** threads.tex 2001/11/13 21:04:15 1.2 --- threads.tex 2001/12/17 09:27:24 1.3 *************** *** 3,8 **** \chapter{Concurrent system programming} ! The Scheme Shell provides you with support for concurrent programming. ! Its interface for concurrent programming consists of several parts: \begin{itemize} \item The thread system --- 3,8 ---- \chapter{Concurrent system programming} ! The Scheme Shell provides the user with support for concurrent programming. ! The interface consists of several parts: \begin{itemize} \item The thread system *************** *** 10,17 **** \item Process state abstractions \end{itemize} ! Whereas the user deals with threads and synchronization explicitly, the ! process state abstractions are built into the rest of the system ! transparent for the user. Section \ref{sec:ps_interac} describes the ! interaction between process state and threads. \section{Threads} --- 10,17 ---- \item Process state abstractions \end{itemize} ! Whereas the user deals with threads and synchronization explicitly, ! the process state abstractions are built into the rest of the system, ! almost transparent for the user. Section \ref{sec:ps_interac} ! describes the interaction between process state and threads. \section{Threads} *************** *** 31,36 **** procedure with no arguments. Note that Scsh's \ex{spawn} does \textbf{not} return a reference to a thread object. The optional ! argument \var{name} is used when printing the thread. \defun {relinquish-timeslice} {} \undefined --- 31,41 ---- procedure with no arguments. Note that Scsh's \ex{spawn} does \textbf{not} return a reference to a thread object. The optional ! argument \var{name} is used when printing the thread. + The new thread will not inherit the values for the process state from + its parent, see the procedure \texttt{fork-thread} in Section + \ref{sec:ps_interac} for a way to create a thread with + semantics similar to process forking. + \defun {relinquish-timeslice} {} \undefined *************** *** 140,153 **** management of operation-system resources'' describes this system in detail.}. The key element in this system is an object called ! \textit{sigevent}, which corresponds to a single occurence of a signal. A sigevent has two fields: the Unix signal that occurred and a ! pointer to the next event that occurred. That is, events are kept in a ! linked list in increasing-time order. Scsh provides various procedures ! to access this list, they are all procided by the structure ! \texttt{sigevents}. \defun {most-recent-sigevent} {} {sigevent} ! Returns the most recent sigevent, that is, the head of the sigevent list. --- 145,157 ---- management of operation-system resources'' describes this system in detail.}. The key element in this system is an object called ! \textit{sigevent} which corresponds to the single occurrence of a signal. A sigevent has two fields: the Unix signal that occurred and a ! pointer to the sigevent that happened or will happen. That is, events ! are kept in a linked list in increasing-time order. Scsh's structure ! \texttt{sigevents} provides various procedures to access this list: \defun {most-recent-sigevent} {} {sigevent} ! Returns the most recent sigevent --- the head of the sigevent list. *************** *** 159,163 **** Returns the next sigevent of type \texttt{type} after sigevent ! \texttt{pre-event}. If no such event exists, the procdure blocks. \defun {next-sigevent-set} {pre-event set} {event} --- 163,167 ---- Returns the next sigevent of type \texttt{type} after sigevent ! \texttt{pre-event}. If no such event exists, the procedure blocks. \defun {next-sigevent-set} {pre-event set} {event} *************** *** 190,213 **** \section{Interaction between threads and process state} \label{sec:ps_interac} - - Global process state is a bad thing: it undermines modularity. In the - case of concurrency however things get even worse. The simplest - example for this it the current working directory. If this would be - global state, no thread can ever reliably dereference a relative link. - - Scsh addresses the problem of process state in a uniform way for - almost all resources. For every global resource there is a - procedure \ex{with-}\textit{resource}\ex{*} \var{thunk} which guarantees that - during the execution of \var{thunk} the resource is - set to the desired value. There is only one exception: The uid under - which the current process is running. The superuser may change to an - arbitrary user without being prompted for a password, but the way back - is blocked. - - ! --- 194,237 ---- \section{Interaction between threads and process state} \label{sec:ps_interac} + In Unix, a number of resources are global to the process: signal + handlers, working directory, umask, environment, user and group ids. + Modular programming is difficult in the context of this global state + and for concurrent programming things get even worse. Section + \ref{sec:event-interf-interr} presents how scsh turns + the global, asynchronous signals handlers into modular, synchronous + sigevents. Concurrent programming also benefit from sigevents as every + thread may chase down the sigevent chain separately. + + Scsh treats working directory, umask and environment as a thread-local + resource. The initial value of the resources is determined by the way + a thread is started: \texttt{spawn} assigns the initial values whereas + \texttt{fork-thread} adopts the values of its parent. Here is a + detailed description of the whole facility: ! \begin{itemize} ! \item The procedures to access and modify the resources remain as ! described in the previous chapters (\texttt{cwd} and \texttt{chdir}, ! \texttt{umask} and \texttt{set-umask}, \texttt{getenv} and ! \texttt{putenv}). ! \item Every thread receives its own copy of each resource. ! \item If \texttt{spawn} is used to start a new thread, the values of ! the resources are the same as they where at the start of scsh. ! \item The procedure ! ! \defun {fork-thread} {thunk} \undefined ! ! from the structure \texttt{thread-fluids} starts a thread which ! inherits the values of all resources from its parent. This behaviour ! is similar to what happens at process forking. ! \item The actual process state is updated only when necessary, i.e. on ! access or modification but not on context switch from one thread ! to another. ! \end{itemize} + For user and group identities arbitrary changing is not possible. + Therefore they remain global process state: If a thread changes one of + these values, all other threads see the new value. Consequently, scsh + does not provide \texttt{with-uid} and friends.