Xref: utzoo comp.os.misc:1402 rec.ham-radio:27762
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ncar!ico!ism.isc.com!ism.isc.com!johnan
From: johnan@ism.isc.com (John Antypas)
Newsgroups: comp.os.misc,rec.ham-radio
Subject: What should a scheduler do?
Message-ID: <1990Dec06.212613.25912@ism.isc.com>
Date: 6 Dec 90 21:26:13 GMT
Sender: usenet@ism.isc.com (Usenet News)
Reply-To: johnan@ism.isc.com (John Antypas)
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 36

Some of us here at ISC are looking into developing a new interface
for the famous KA9Q program under Unix.  While KA9Q works under Unix,
it is a monolithic program handling all client and server tasks.
We would like to split this apart such that clients and servers need
not run as the same process.

To do this, we envision something like:


         Clients....Clients...Clients....
                \------|--------/-----\
                 Networking Layer------Scheduling Layer
                       |                   |
                      O/S Specific Interface Layer

The above approach would allow to develop clients and servers to use
a specific set of networking and OS call and not worry about whether
we're running AX.25, TCP/IP, SNA/LU6.2 et al. on Unix, DOS, WIN 3, AmigaDos
et al.

First question:

What should a multi-processing interface library allow access to?  

Process creation, destruction, task prioritizing etc...

What should a networking layer handle?

Set up, Teardown, vc byte streams, datagrams et al.

Comments as always, are welcome...

John Antypas / Interactive Systems Corp. .!uunet!ism!johnan johnan@ism.isc.com
All statements belong to author.

"Help!  I've crashed -- and I can't reboot!!" -- oracle@iuvax.cs.indiana.edu