Re: Process Control Extensions - kill/reset/throw scheduling, exception handling

Philipp, All,

Good point about not propagating two exceptions. I will include some
wording to point out this implementation constraint.

In summary

- is_unwinding() returns true after sc_unwind_exception has been thrown by
the kernel but not yet caught by the kernel
- sc_unwind_exception::is_reset() can be called to distinguish kill from
reset
- it is an error for an application to catch but not re-throw
sc_unwind_exception
- it is an error for an application to call wait() or next_trigger() when
is_unwinding() == true
- "an error" implies that the implementation shall throw an sc_report
object (assuming the report handler is in its default state)

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
SystemC P1666 Technical <systemc-p1666-technical@eda.org>,
owner-systemc-p1666-technical@eda.org
Date:
02/09/2010 18:43
Subject:
Re: Process Control Extensions - kill/reset/throw scheduling, exception
handling

John,

comments below.

On 02/09/10 14:59, john.aynsley@doulos.com wrote:
>
> Okay, I will take it as given that we are going to remove the
restriction
> that "The kernel shall not cause or allow any other process instance
to
> run between the call to kill and the return of control"

+1 from my side.

> How about sc_process_handle::is_unwinding() ? Are we agreed that we will

> add this method? It shall return true if and only if called in the
context
> of a catch block for sc_unwind_exception.

I think the duration as defined by Bishnupriya is more accurate:

[bpriya: yes, this is a good addition - you provide a valid rationale in
your earlier mail. We need to precisely define the semantics of
sc_process_handle::is_unwinding(). It certainly applies to kill() and
reset() - it will be true just before the kernel throws
sc_unwind_exception and will be false after kernel catches
sc_unwind_exception. What about throw_it()? I'm thinking it does not
apply to throw_it().]

  The main use case is within a destructor of a local object, called
during unwinding (and therefore not within a catch block). Consider the
following example (a stripped down time annotation technique):

class wait_on_exit
{
  ~wait_on_exit() {
    if( !sc_is_unwinding() ) // needed, because we might get killed
      wait( 10, SC_NS ) ; // ... and this wait would be illegal
  }
};

void some_module::some_process()
{
  while( true )
  {
    try {
      wait_on_exit w; // local object, destroyed before catch
      // ...
    } catch( const sc_unwind_exception& ) {
      // some other cleanup
      throw;
    }
  }
}

And I agree, that this does not apply to throw_it(), since an
implementation can not reliably detect the "end" of the unwinding within
the application code without additional requirements regarding the
thrown objects.

> Phillipp wrote "- Should an implementation be obliged to detect, when an

> application calls the scheduler (wait, etc.) during unwinding? Or if it

> even swallows kill/reset requests completely? (IMHO, yes)"
> B'priya wrote: "Yes, I think that will be good to have"
>
> I think the current spec requires detection of the case where a process
> swallows an sc_rewind_exception: it is an error.

The version of the spec on eda.org (which is most probably out-of-date)
says on this:

"If a process so desires, it can provide a handler for sc_kill_exception
in its function body, for example, to perform some exit cleanup. In such
cases, the handler shall throw back the sc_kill_exception so that the
implementation can also handle the exception and take the right action."

But the handler is part of the application. That's the reason for my
proposal to explicitly require the detection of these cases.

> What about the case when
> an application calls wait or next_trigger while unwinding? Are we agreed

> this case is an error too? (Remember, in 1666, "error" requires that the

> implementation calls sc_report_handler::report). I think these are the
> only two calls that are relevant in this context.

Yes, I think it should be the same here. Issuing additional
kill/reset/throw_it calls is ok, I think? With the immediate semantics,
they involve the scheduler as well.

  Note, that there are implementation constraints, since there might
still be an uncaught exception (e.g. in the destructor example shown
above). When the error report has an SC_THROW action, this would lead
to a call to std::terminate by the rules of C++ since you can't have two
exceptions being propagated at the same time. Does the wording "shall
be an error" imply an SC_THROW action?

Thanks,
  Philipp

[snip previous mail quotations]

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
R&D Division Transportation | FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.