Real Time Scheduler

Created: 21.7.97
Modified: 16.9.97
Contents:

Description and features
Commands
Programming interface
Sources

1. Description and features

The RTS is a cron-like system comprising a session queue database, generic access commands and a C++ API. It is designed to efficiently interface the RTSP protocol layer to the following categories of Unix-based applications with minimal effort:

Services that are otherwise fully functional and lack the RTSP protocol layer and the associated real time formalization.
Database applications that can handle multiple threads of access but not real time.
Simple real time applications that can handle their own task queues.
Session programs that need to be commanded to start or stop at scheduled times.
Task programs that play or record, and must be initiated and killed at scheduled times.

RTS treats each RTSP session as a thread of activity comprising a sequence of tasks representing play/record requests. That is, each thread is simply a queue in the database, and has nothing to do with POSIX or Java threads. A single cron-like demon runs optionally to periodically check the database and initiate or terminate application tasks according to their wallclock schedules. The database is kept in shared memory to simplify access by independent command and application processes.

The scheduler has the following features:

Uses upto one demon process per database (ie. shm).
Demon examines the database at intervals programmable in millisecs.
Demon is woken up for pausing and continuation of requests.
Can run media processes in either per-thread or per-task fashion.
Supplies predefined runtime arguments to media processes.
Supplies request and pause parameters to media processes.
Allows use of signals for pausing and resuming.
Can be configured to deliver play/pause requests immediately or at scheduled times.

2. Command interface

Synopsis

	rtcreate [-f path] [-m mode(0700)] [-p poll(0)] [-s size(200K)]
	rtvers shmid
	rtstat shmid
	shmstat shmid

	rtnew shmid data
	rtdel shmid tid
	rtlease shmid tid [leasetime]

	rtrun shmid intvl(ms,-1=once) prog args

	rtstop shmid -a
	rtstop shmid tid -f
	rtstop shmid tid (clock:npt:smpte) at

	rtplay shmid tid options.. otherparams..
		[-F rangetype(npt|smpte|clock|utc)(npt)]
		[-S speed(1.0)]
		[-T smpteType(E=EBU,2=24,3=30,D=30-drop)(D)
		[-r /* record */]
		[-s start(0)]
		[-f finish(-)]
		[-t time(now)]

	rtsignals shmid sigpause sigresume

Description

Rtcreate creates and initializes a new database shm and prints the shmid to stdout. Rtvers prints the version of the database in shared memory, and is a useful debug tool when modifying the database structures. Rtstat prints the database to stdout in a readable format. Shmstat dumps the shared memory allocation structure, and helps track down memory leaks.

Rtnew creates a new thread, ie. an RTSP session, and assigns thread-specific data, such as transport parameters and destination address. Rtdel destroys a thread, corresponding to an RTSP teardown, provided the thread is already inactive. Otherwise it prints a busy message. Rtstopid must be used to terminate an active thread before attempting to dismantle it.

In the once-only mode, rtrun runs a specified prog with given args in exactly the same manner that the program would run as a task. Otherwise, rtrun runs as a demon waking up every so many milliseconds to examine the database for runnable and stoppable tasks. Rtstop wakes up the demon to ensure termination at the right millisecond. The demon is also woken up automatically whenever a task completes (or dies) and the thread (session) has a further request waiting. The following script illustrates the correct invocation of the media player:

	#!/bin/ksh

	# command args supplied with prog arg to rtrun, rtrunid.
	while [ $1 ]
	do
		echo "Arg:$1"
		shift
	done

	# thread and task-specific data given by rtrun.
	# caution:
	#	if no parameters, the shell will hang at read.
	while read line
	do
		echo "Param: $line"
		[ "$line" ] || break
	done <&3
	echo "End $$"

Rtrun can be made to run one process per task or one process for an entire thread, depending on how the media player program is written. In the first case, the program must be started for each play request and terminated before the next request is serviced. In the second, rtrun needs to asynchronously convey pause and resume instructions to the media playing process. Both modes of operation are implemented by sending signals to the playing process. For the first mode, the pause is signalled by SIGTERM, which gracefully but forcibly terminates the process. For the second, the default pause signal must be downgraded to to a catchable signal that can be ignored, and a similar non-zero resume signal must be specified, using the rtsignals command.

Only the time parameters are interpreted by these commands. Other RTSP parameters must be parsed and interpreted by the media programs.