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 
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 12 04:50:25 2011
This archive was generated by hypermail 2.1.8 : Wed Jan 12 2011 - 04:50:28 PST