Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.misc Subject: Re: Multitasking Definitions (Was: True Multitasking) Message-ID: Date: 28 Jan 91 16:51:14 GMT References: <1991Jan18.055614.13889@zorch.SF-Bay.ORG> <42149@nigel.ee.udel.edu> <15750@sdcc6.ucsd.edu> <7641@sugar.hackercorp.com> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 30 In-Reply-To: peter@sugar.hackercorp.com's message of 28 Jan 91 12:38:02 GMT In article <7641@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: In article mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > [CRs take] responsibility for saving whatever state it needs to restart. What state is this? A coroutine's state is just its stack, and that's saved by the co-call. Yes, there's very little state. But it's saved by the co-call, which is part of your program. You deleted the comparison to LWPs, where the state is saved by something outside of your program. > Further, if you're willing to do the appropriate magic, you can get > LWPs without OS support specifically for them; but it's a lot of fuss. All you need is the ability to set up a stack context, and switch to another stack. Then add a round-robin scheduler. It's not a *lot* of fuss but it does tend to be machine, compiler, and even compiler revision dependent. Ok, so it depends on what you consider a "lot". As an exercise, implementing co-routines isn't a lot of fuss. As part of another project where it's a distraction from solving the problem, it can be.