Re: Children of dead processes

Yes, exactly.

Additionally, this has implications for the invalidation of process
handles as well, right?

Philipp

On 12/01/11 13:49, john.aynsley@doulos.com wrote:
> Bishnupriya, Philipp,
>
> Agreed. So as I understand it, we are proposing that for every occurrence
> of get_parent_object() in the LRM, we change the description to say that
> the following:
>
> If the parent object is a process instance and that process has
> terminated, get_parent_object shall return a pointer to the process
> instance. The parent process instance shall not be deleted while the
> process instance has child objects, but may be deleted once all its child
> objects have been deleted
>
> Right?
>
> John A
>
>
>
> From:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "philipp.hartmann@offis.de" <philipp.hartmann@offis.de>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 11/01/2011 18:14
> Subject:
> RE: Children of dead processes
>
>
>
> John,
>
> Philip raises excellent questions, and I?m very much in favor of mandating
> that parent process objects with live children should not be deleted. It
> provides a nice, clean, intuitive semantics with no ?surprises? for the
> user.
>
> Thanks,
> -Bishnupriya
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Tuesday, January 11, 2011 6:04 PM
> To: Bishnupriya Bhattacharya; philipp.hartmann@offis.de;
> systemc-p1666-technical@eda.org
> Subject: Children of dead processes
>
> All,
>
> Philipp has raised the following issues:
>
>
> 6.6.5 sc_process_handle::get_parent_object
> 6.16.7 sc_object::get_parent_object
>
> "If the parent object is a process instance and that process has
> terminated, get_parent_object shall return either a pointer to the
> surviving process instance or a null pointer if it has been deleted."
>
> What happens to the object's position itself, when the parent object is
> NULL?
>
> - It can still be found via sc_find_object( obj.name() )?
>
> - Is it moved to the top-level, i.e. can it be found via
> sc_get_top_level_objects()?
>
> - But then basename() != name(), but (since no parent)
> get_parent_object()->name() '.' basename() != name()
> (The name can't be changed, since it is meant to stay valid until the
> object is deleted?)
>
> This may affect sc_event naming as well.
>
>
> 6.16.1 sc_object Description (see get_parent_object above)
>
> "... objects of a class derived from sc_object may be deleted at any
> time. When such an sc_object is deleted, it ceases to be a child."
>
> If it has child objects itself (in case of a process), what happens to
> their position in the hierarchy? And their names?
>
> I would even prefer to have a restriction that in case, the "parent"
> object shall not be deleted/invalidated until all children have been
> deleted. But this might break "early invalidating" implementations.
>
>
> [JA] We have already agreed that dynamic processes may be terminated while
> they still have children, in which case a call to get_parent_object() for
> any orphaned objects returns a null pointer. On the other hand, insisting
> that parent process objects cannot be deleted while they have surviving
> children would be a clean solution.
>
> Opinions?
>
> John A
>
>
>
>

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