Re: Children of dead processes

John,

is there any reason to invalidate a process handle, if the underlying
process object continues to exist (and logically points to the same
instance, i.e. is not yet re-used)?

  I would even prefer to allow the deletion of such parent objects over
having this mismatch between child.get_parent_object() and invalidated
handles.

  From an implementation POV, one could still create new handles via
sc_process_handle( child.get_parent_object() ), right? We would then
have to make it implementation-defined, if handles of terminated
processes can be created.

Greetings from Oldenburg,
  Philipp

On 12/01/11 17:54, john.aynsley@doulos.com wrote:
>
> Indeed. An implementation may choose to invalidate any process handles as
> soon as a process instance terminates. In the case of a terminated process
> with children, we have to decide whether the implementation is obliged to
> keep any process handles valid as long as the process object continues to
> exists. Otherwise we may have the situation where there exists a
> non-terminated child process whose parent process continues to exist but
> has an invalid handle. I do not see this is a problem, but it does seem a
> little odd.
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> Bishnupriya Bhattacharya <bpriya@cadence.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 12/01/2011 14:53
> Subject:
> 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.