Xref: utzoo comp.os.misc:1407 rec.ham-radio:28435 Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.os.misc,rec.ham-radio Subject: Re: What should a scheduler do? Message-ID: Date: 16 Dec 90 23:46:27 GMT References: <1990Dec06.212613.25912@ism.isc.com> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 44 Nntp-Posting-Host: teachb In-reply-to: johnan@ism.isc.com's message of 6 Dec 90 21:26:13 GMT On 6 Dec 90 21:26:13 GMT, johnan@ism.isc.com (John Antypas) said: In article <1990Dec06.212613.25912@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: johnan> Some of us here at ISC are looking into developing a new johnan> interface for the famous KA9Q program under Unix. While KA9Q johnan> works under Unix, it is a monolithic program handling all client johnan> and server tasks. We would like to split this apart such that johnan> clients and servers need not run as the same process. What you want to do is essentially a network server like Mach, or user implemented domains like 4.2BSD (not yet implemented). Your network server is a (possibly multithreaded) process that takes "messages" from local processes, packs them up, and then accesses the hardware interface to send them over a particular medium (or viceversa of course). To do it under Unix it is almost essential to have the ability to pass file descriptors in "messages", and to poll()/select() (the latter to simulate multithreading within the server). STREAMS does offer you these abilities, and so does UNIX domain IPC. I'd rather go with STREAMS on System V, even if you have a socket library. I would go with a clone of the AT&T TLI as the API. When you try to open a connection, you must specify a transport provider; the library would then open a well known named stream to the KA9Q server (instead of linking to a multiplexor in the kernel and pushing modules therein), ask it to create an appropriate connection, associate it a file descriptor, and then return over the well known named stream that file descriptor. I think this can be easily implemented also under monotasking OSes; transferring the file descriptor/handle from the "server" to the "client" would just involve an assignment... If you want extra details, read the Accent IPC TechReps from Carnegie Mellon, and the Mach documentation on network servers. If one is prepared to be clever (hacking the Unix scheduler a bit would help), the cost of two context switches on every transaction can be duly minimized. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk