aduncan@rhea.trl.oz (Allan Duncan) (11/15/90)
From article <6874@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): ... > written so that it runs tasks in a protected mode when available so that > forks would be cheap (otherwise you'd want to defer the forking task until > the child exits or execs... with some reasonably long timeout: forks on > a 68000 without MMU are ugly... look at how MINIX does it). I have seen discussion on forking and how hard it is on the Amiga, but since I don't dwell on O/S theory (I just use the things) I do not follow the nitty gritty of why it is hard. Tutorial anyone? Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
jesup@cbmvax.commodore.com (Randell Jesup) (11/16/90)
In article <2478@trlluna.trl.oz> aduncan@rhea.trl.oz (Allan Duncan) writes: >From article <6874@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): >... >> written so that it runs tasks in a protected mode when available so that >> forks would be cheap (otherwise you'd want to defer the forking task until >> the child exits or execs... with some reasonably long timeout: forks on >> a 68000 without MMU are ugly... look at how MINIX does it). > >I have seen discussion on forking and how hard it is on the Amiga, but >since I don't dwell on O/S theory (I just use the things) I do not >follow the nitty gritty of why it is hard. fork() ala Unix is hard, since it assumes an MMU, as well as assuming that all processes share the same set of logical addresses. Without an MMU, since the data and stack have absolute references, to implement fork(0 you must: a) clone the data and stack into two save areas, b) every time one of the two processes gets to run, you must copy it's saved data area into the original area, and the other's back to its save area (assuming the other was the last to run). This is quite expensive (especially if both processes remain around and active for a while without exec()ing. If one goes to sleep, or execs, then you stop paying most of the penalty from then on.) Even this won't work unless you have a single-tasked kernal (for example, if the I/O driver might wait for a seek, and you let another task run, the memory area to be read/written might now be occupied by the other process.) Therefore you can't use this method to fork() on the Amiga under AmigaDos, though AmigaMinix can (and does) use it. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
peter@sugar.hackercorp.com (Peter da Silva) (11/16/90)
In article <15900@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Even this won't work unless you have a single-tasked kernal (for > example, if the I/O driver might wait for a seek, and you let another task run, > the memory area to be read/written might now be occupied by the other process.) > Therefore you can't use this method to fork() on the Amiga under AmigaDos, > though AmigaMinix can (and does) use it. Well, if you work through a posix.library that does reads and writes through a buffer pool, like in UNIX, then you could still use fork(). This just becomes another thing to watch out for... it's not a show stopper. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.