        SF -- Scheduler Framework
        =========================

Author:  Juhana Rsnen / Helsinki University of Technology
Version: 0.05 (August 21 1997)


INTRODUCTION
============

Scheduler Framework is intended to be a simple framework for scheduling
objects in C++ applications. Its functionality and interface is as lean
as possible to facilitate easy implementation of different schedulers,
scheduling policies, combinations of event loops, etc. without affecting
the applications that use SF. This may mean a little more work when
building an application, but provides greater flexibility than a richer
framework would do. The reason why SF does not define its own timers,
devices, messages, etc. is that SF is only a low-level object scheduler
rather than a full-blown OO virtual operations system. The mentioned
higher level functions could be implemented either in an application
specific way or as separate frameworks, but the framework approach is
more recommendable, because it results in better overall structure of
the application.

Currently the interface to SF consists of only three classes: sfScheduler,
sfTask and sfSchedulerHandle. Simply put, sfTasks can request i) execution
ii) timeouts or iii) asyncronous I/O from a sfScheduler by calling methods
of the sfScheduleHandle. The function of a sfScheduler is to respond to
these requests according to some scheduling policy defined by the
implementation of the scheduler. When the requests of the sfTasks become
executed in the main loop of the scheduler, respective callback methods
of the sfTask interface will get called.

All three classes are abstract base classes, so building an application
based on SF requires the developer to define implementations specific to
the application under development. SF includes an instructive implementation
of a simple FIFO-scheduler and a demo program. The demo program illustrates
usage of SF style scheduling, including all three elements (execution,
timeouts and asynchronous I/O).

As a new scheduler since version 0.04 SF includes also sfORBScheduler that
is a scheduler capable of driving both SF and OmniBroker ORB event loops.
For more information about OmniBroker can be found at http://www.ooc.com/.
Note that to use sfORBScheduler you must have OmniBroker version 1.0 or
higher installed to your system (or at least have OB include files and
libOB.a available).



CLASSES
=======
o sfScheduler
    The base class for schedulers. Its class interface includes methods
    only for running the scheduler and requesting scheduler handles from
    the scheduler. It is intended that a task that wishes to become
    scheduled requests a handle from the scheduler and calls the methods
    of the handle to inform the scheduler of itself. The handle takes
    care of the interface to the scheduler (see below).
    SF includes an implementation of a simple scheduler (sfFIFOScheduler),
    but it is intended to be demonstrative only. Applications requiring
    more sophisticated scheduling policies than FIFO or combination of
    e.g. CORBA or X event loops need to define their own schedulers.
    There is also a scheduler (sfORBScheduler) that merges OmniBroker
    ORB and SF event loops.

o sfTask
    The base class for tasks. Includes request methods for scheduler
    services mentioned above as well as callback methods that will
    get called when the request gets served. The request methods are
    provided for simpler interface between scheduler and tasks, but
    it is not necessary to use them. Base class callback methods have
    default implementations that print an error message and exit. This
    has two benefits: firstly, the derived class that doesn't need some
    particular callback method doesn't have to implement it, and on the
    other hand the error-exit function helps to find programming errors.
    Tasks also have default implementations of priority and load for
    use as scheduling parameters. More parameters can be added to the
    implementations.

o sfSchedulerHandle
    The purpose of the scheduler handles is to hide the implementation
    of a concrete scheduler behind the interface provided by the handle,
    this method also known as Bridge pattern. Tasks can request shceduled
    events such as execution, timeouts or asynchronous I/O, but how these
    requests are implemented within a concrete scheduler is only known to
    the handle classes that are supposed to be internal classes of the
    schedulers (see sfFIFOScheduler for an example).

o Exception classes
    All exceptions thrown by SF are defined in exception.{h|cpp} files.

o OTime
    Helper class to represent time, legacy from the OVOPS package.
