Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!unixhub!shelby!agate!darkstar!uunet.UU.NET!decwrl!apple.com!motcsd!greek!lance
From: decwrl!apple.com!motcsd!greek!lance@uunet.UU.NET
Newsgroups: comp.os.research
Subject: Re: How light weight can a process get?
Message-ID: <9585@darkstar.ucsc.edu>
Date: 30 Nov 90 01:22:02 GMT
Sender: usenet@darkstar.ucsc.edu
Lines: 35
Approved: comp-os-research@jupiter.ucsc.edu

jms@central.cis.upenn.edu (Jonathan M. Smith) writes:



>Notes on "lightweight" processes

>1. I wanted to see how minimal a process could be created, assuming I was
>willing to give up address space protection. For experimental purposes, I
>also focused on an ideal scheduling method, i.e., co-routine scheduling.
>The method I used was to use the facilities setjmp() and longjmp() which
>are provided by the C library. They provide the ability to achieve a non-local
>goto, that is, one which crosses routine boundaries. setjmp() saves the current
>"state" of the program (i.e., a minimal set of registers, floating registers,
>frame pointers, etc) into a jmp_buf structure 
>(see /usr/include/setjmp.h) and longjmp(),
>given a jmp_buf, restores the specified state, including the program counter.


A "neutrino-weight" process:

process_a() {
	static state = 0;

	switch (state) {
		case 0:		do_something(); state = 1; break;
		case 1:		do_something_else(); state = 0; break;
	}
}

The setjmp/longjmp hack is handy.  The only problem with it is that
you have to allocate separate stack RAM for each thread, and if your
operating system doesn't support a separate signal stack, running out
of stack causes the program to die.

Lance