The RVR_THREADS Interface

RVR_THREADS is a threads package that is independent of Horus. It is fast and advanced. The main thing missing right now is that it doesn't actually support multi-processors. Also, it doesn't have true pre-emption (hard to do under UNIX). An important thing to know is that we decided to stop pushing threads in Horus. We will keep on supporting them, but now we're pushing automata. Most of the spiffy system call interception features of rvr_threads are also supported by these automata, so that the socket library and the Tcl/TK interface keep on working. Horus application writers that do not use the socket interface are encouraged to use the Horus thread interface.

Although users can deal with input from multiple sources using UNIX select() (which rvr_threads supports nevertheless), it is often awkward. Often multiple threads are much more natural for such applications as performing multiple RPCs in parallel, and reading terminal input. Since Horus applications typically do have to deal with multiple activities, rvr_threads supports a flexible multi-threading environment that is compatible with the UNIX interface.

This page only describes the most important things to know. We refer to the top of the source code file "machdep/nbsd/rvr_thread.c" for more precise documentation, and to the bottom of this file for examples.

SOURCES

machdep/nbsd/rvr_thread.h
machdep/nbsd/rvr_thread.c

INCLUDE

#include "muts.h"

INTERFACE

int t_start(
	stackpool_id     stackpool,
	void	         (*pc)(void *, void *),
	void	         *arg1,
	void	         *arg2,
	void	         *ident,
	int	         priority,
	struct itimerval *it
);

The stack pool specifies where to allocate the stack, and in particular the stack size (see t_stackpool() below). By specifying 0 a default stack is allocated. pc specifies which routine to invoke, which is invoked with two parameters: arg1 and arg2. ident is a pointer that is associated with the thread, and is used mostly for debugging (0 may be specified).

The priority may be set to any non-negative integer value (the value --1 is used for the idle loop). Higher priority threads are always scheduled before lower priority threads. Threads of the same priority are scheduled in round-robin order. Per default, scheduling is non-preemptive, but see pre_enter and pre_exit below.

The it value is as in the UNIX setitimer interface. When null, the thread is created immediately. When non-null, the it_value field specifies when to start executing the thread. The thread may be scheduled periodically by specifying a non-zero it_interval field. Note that Horus does not support setitimer and getitimer.

A thread terminates by returning from the pc procedure. There is no thread exit routine. Users that wish to jump out of the middle of a thread have to use the normal UNIX setjmp and longjmp interface.