From owner-mint@fishpool.com Fri Jul 11 19:48:32 2003 Date: Fri, 11 Jul 2003 19:46:10 +0200 (CEST) From: Frank Naumann X-X-Sender: fnaumann@wh58-508.st.uni-magdeburg.de To: Ingo Schmidt cc: MiNT-Liste Subject: Re: [MiNT] Prusage(), Signals In-Reply-To: <705259933.20030711183636@der-ingo.de> Message-ID: References: <705259933.20030711183636@der-ingo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *19b1wa-0000NE-00*oSqNy20/mrM* (Otto-von-Guericke Universitaet Magdeburg, Germany) 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: fnaumann@cs.uni-magdeburg.de Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Hello! > Prusage(): > > r[0] = process time in kernel > r[1] = process time in own program code > > Does this mean I have to add those two times to get the overall time > the process has been running? I guess so. Yes. > And what does "process time in kernel" mean? Do VDI and AES also count > in here? E.g. if a VDI routine took a long time I will see that in > r[0]? Yes. > This looks very similar to Pmsg() in mode 2 (send message and then > wait for one). Andideally this will work, too. But since we have > multitasking, the following might occur: > > A: Pexec(B) > (now the OS switches tasks to process B, so A has not executed Psigpause() yet) > B: Pkill(A, SIGCONT) > B: Psigpause() > A: Psigpause() > > So this is my question: > Will I have a deadlock now? Yes. > Or does A immediately wake up again, > because the earlier SIGCONT signal was buffered? I read the docs, but > they are ambiguous here!! It is not celar to me what happens with the > signals. If a signal is delivered to the process the following happen: - the signal is first marked as pending for the process - if the signal is not blocked by the process, the process is woken up and moved to the ready queue (if not already there) - on the next context switch to the process the kernel check for pending signals; if there is something pending the signal handler for the process is invoked imediatly (instead restoring the context) - now the signal handler run - if a signal is blocked it's only marked as pending; nothing more is done - if a signal is unblocked it's checked if the signal is pending; if yes the signal handler is invoked immediatly This means, yes, you can get deadlocks with your simple model. To avoid deadlocks you must block/unblock the Signals on the right places. > I want to know this because I want to use the above scenario as a > (bad) replacement for Pmsg() under MagiC. But of course I do not want > deadlocks... You should test if the signal semantic on MagiC is really compatible. Ciao ...Frank -- ATARI FALCON 040 // MILAN 060 ----------------------------------------- http://www.cs.uni-magdeburg.de/~fnaumann/ e-Mail: fnaumann@freemint.de