Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.misc
Subject: Re: TYpeahead implementations (Re: How do we change the scheduler? (Was Re: Multitasking at home...))
Message-ID: <11015.tnews@templar.actrix.gen.nz>
Date: 7 Feb 91 23:49:06 GMT
References: <10640.tnews@templar.actrix.gen.nz> <7643@sugar.hackercorp.com> <10856.tnews@templar.actrix.gen.nz> <7706@sugar.hackercorp.com>
Organization: TAP, NZAmigaUG.
Lines: 54

Quoted from <7706@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva):
> In article <10856.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

> >     go to line 124... under MS-DOS these keystrokes go to MicroEMACS.
> 
> Unless MicroEmacs opens a window of its own under DesqView or Microsoft

    Neither of these are "MS-DOS". Nor are they monotasking.

> > On a single-tasking system, the
> >     input is much more likely to behave in an unshared way like MS-DOS,
> >     which is the basis of my statement above.
> 
> You mean like on the Macintosh?

    The problem of multiple input paths is as much a GUI problem as it is a
    multitasking problem, so the Mac may "suffer" too. Maybe to a lesser
    degree.

> > Under programs that
> >     continued to take input from the console they were started from (ie:
> >     stayed within a single task), you'd be correct. Very few programs
> >     I use do this.
> 
> They all stay in the same task. This has, for the second time, nothing

    No, the ones I use do not stay in the same task. Eg:

    alias v = "ty [] &"
    alias m = "mostra [] &"
    alias e = "McrEMACS [] &"

> to do with multitasking. Nothing. Nada. Zip. Zero.

    The presence of multitasking makes the problem more likely. In the
    specific sample set given (MS-DOS and the Amiga) this is exactly why
    the problem exists. Even in cases where the shell is blocked from
    executing commands while a program is running, it's input task (take
    a look in a task list at all the "CON"s, for example) is still
    active.

> In fact Emacs *is* still running in the shell you started from, and you
> can't give *it* any more commands until Emacs finishes.

    No, see above. And even if I _was_ the sort of person that allowed
    large programs to tie up my main shell, I can send the shell more
    commands while using MicroEMACS - they would not be executed until
    MicroEMACS finished, but they would not be swallowed by MicroEMACS
    either.

> Peter da Silva.   `-_-'
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***