From fnaumann@mail.cs.uni-magdeburg.de Wed Jan 28 18:21:44 2004 From: Henk Robbers To: mint@fishpool.com Subject: Re: [MiNT] fVDI issues Date: Wed, 28 Jan 2004 18:15:27 +0100 User-Agent: KMail/1.5.1 References: <20040122144133.GC17739@haddock.cd.chalmers.se> <07ba01c3e58b$26865ae0$0e0a63d9@blaszak> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401281815.27978.h.robbers@chello.nl> Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: h.robbers@chello.nl Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: On Wednesday 28 January 2004 17:00, Frank Naumann wrote: > Hello! > > > I see no reason nor any advantages of a situation when functions like > > objc_draw() or fsel_exinput() should run in supervisor mode as a part of > > the kernel. Honestly, I cannot even imagine the GEM fileselector opening > > and waiting in supervisor mode for user interaction. This would be a > > nonsense. > Well, XaAES runs in user mode. > Btw it's just a matter of the viewpoint: if an application wait for > keyboard input it's only on the kernel I/O queue and the kernel will > schedule the process if I/O is possible. You can see a fileselector in > exactly the same way (waiting for I/O). > Precisely. If you look in XaAES you will see that this is exactly waht happens. XaAES immediately suspends the application, and then itself waiting for approppriate event. So while a FS is on the screen neither XaAES nor application are running. Very good for multitasking. -- Groeten; Regards. Henk Robbers. mailto:h.robbers@chello.nl http://members.ams.chello.nl/h.robbers/Home.html Interactive disassembler: TT-Digger; http://digger.atari.org A Home Cooked teXt editor: AHCX