Makes sense to me.
David C Black
On Jul 22, 2010, at 10:43 AM, john.aynsley@doulos.com wrote:
> Bishnupriya,
>
> It's nice to be able to catch and handle kills and resets, but I don't think it's important enough to justify anything but the simplest mechanism. I would have thought that most of the time kills and resets could be handled in the same way.
>
> I was musing on some other way of telling whether the process had been killed or reset, and method terminated() came to mind, but presumably a killed process would not get terminated until the exception was caught by the kernel, so that's no good.
>
> I am arguing semantics here, but if we have a common exception, that exception does not necessarily terminate the process, because it is being used for both reset() and kill(): reset() does not leave the process terminated. So having class sc_kill_exception: public sc_reset_exception makes more sense to me, with the sc_reset_exception actually doing the work of unwinding the stack. Does that work?
>
> John A
>
>
> From: David C Black <dcblack@xtreme-eda.com>
> To: systemc-p1666-technical@eda.org
> Date: 21/07/2010 21:16
> Subject: Re: reset method
> Sent by: owner-systemc-p1666-technical@eda.org
>
>
>
>
> If you're going to throw an exception anyhow, then I would prefer the sc_reset_exception solution over adding another member method.
>
> ------------------------------------------------------
> David C Black, XtremeEDA ESL Practice Leader
> http://www.Xtreme-EDA.com
> (Consulting, Services & Training for all your ESL, verification and DFT needs)
> Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609
>
> On Jul 21, 2010, at 2:49 PM, Bishnupriya Bhattacharya wrote:
>
> John,
>
> Yes reset() throws an sc_kill_exception.
>
> It is a good idea to distinguish reset from kill by using the exception. I suggest a member method in the sc_kill_exception class - "bool reset()" - or perhaps have sc_reet_exception that derives from sc_kill_exception?
>
> WDYT?
>
> Thanks,
> -Bishnupriya
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jul 22 09:15:25 2010
This archive was generated by hypermail 2.1.8 : Thu Jul 22 2010 - 09:15:27 PDT