From owner-mint@fishpool.com Fri Jul 11 18:45:34 2003 Date: Fri, 11 Jul 2003 18:36:36 +0200 From: Ingo Schmidt X-Mailer: The Bat! (v1.62q) Personal Reply-To: Ingo Schmidt Organization: onlinehome.de X-Priority: 3 (Normal) Message-ID: <705259933.20030711183636@der-ingo.de> To: MiNT-Liste Subject: [MiNT] Prusage(), Signals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: ich@der-ingo.de Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Hi! Two questions: 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. 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]? Signals: Imagine the following situation (process A und process B) A: Pexec(B) A: Psigpause() B: Pkill(A, SIGCONT) B: Psigpause() A: Pkill(B, SIGCONT) A: Psigpause() B: Pkill(A, SIGCONT) and so on... 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? 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. 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... Cheers, Ingo =;->