RE: Process Control Extensions

John,

First, I would like to clarify If I understand you right, and then comment on my position later.

What you propose below is essentially changing what the LRM says today about what should happen when a process terminates.

Today the LRM leaves it upto the implementation - it can choose to delete the process object or not, it can choose to invaldiate associated process handles or not.

What you propose is that the LRM mandates when a process object terminates, and it has any live children (actually live descendants by applying this rule recursively), it is obligated to

1) not delete the process object
2) not invaldiate any associated process handles

In my mind, this can be considered orthogonal to the process control extensions, and can simply stand on its own as a modification to the LRM. The connection to the process control extensions is that this change provides a clean/unambiguous definition of "descendants" of a process handle, which benefits the include_descendants clause in the process control constructs.

Does this correctly interpret your proposal?

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, May 24, 2010 5:50 PM
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: RE: Process Control Extensions

Bishnupriya,

That is not quite what I had expected you to say, so we need to look a bit deeper 8=)

I had expected you to say that the specification of include_descendents was independent of whether or not an implementation chooses to invalidate process handles so that include_descendents would always find all living descendents, direct or indirect, regardless of whether any intermediate process objects had been deleted or process handles invalidated. You seem to be saying that whether or not an implementation chooses to invalidate handles can have an effect on the set of processes found by include_descendents.

Thinking about it, a similar point applies to sc_process_handle::get_child_objects. We say that get_child_objects excludes deleted process objects, but that an implementation can choose whether or not to invalidate process handles and delete process objects for terminated processes. In summary, we have:

* process terminates => implementation can choose whether or not to invalidate process handle
* valid handle => process object still exists
* invalid handle => implementation can choose whether or not to delete process object
* get_child_objects could return a terminated process object with valid or invalid handles
* get_child_objects excludes any deleted process objects

From the above, it is in general implementation-defined whether a process can find its living grandchildren (because its children may have been deleted).

It would make more sense to me if an implementation were NOT ALLOWED to invalidate a process handle or delete a process object while that process still has living children. It is one thing for the retrieval of dead children to be implementation-defined (sorry to be so morbid), but quite another for the retrieval of living grandchildren to depend on the implementation. What do you think?

John A

From: Bishnupriya Bhattacharya <bpriya@cadence.com>
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date: 17/05/2010 08:02
Subject: RE: Process Control Extensions

________________________________

John,

The process control extensions do not impose any additional constraint on the validity of process handles over and above what the LRM already specifies. Currently the LRM says

"When the underlying process instance terminates, an implementation may choose to invalidate any
associated process handles but is not obliged to do so. In other words, when a process terminates, an
implementation is neither obliged to keep the handle valid nor to invalidate the handle."

In your example, after B terminates, if a process control extension is invoked on A with the include_descendants clause, one of two things can happen

1) if an implementation invalidated process handles associated with B as soon as B terminated, the process control extension will not be able to find B or C as decendants of A, and will not apply to B and C.

2) if an implementation kept the process handles associated with B valid after B terminated (say beacuse it had live children), the process control extension will be able to find B and C as descendants of A and will also apply to B and C.

An implementation need not to do anything special to choose 1) or 2). It should automatically fall out - note that sc_process_handle::get_child_objects() returns an empty vector if the handle is invalid.

Does this clarify the intent?

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, May 14, 2010 4:42 PM
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: RE: Process Control Extensions

Bishnupriya,

* Is include_descendants intended to find descendents of intermediate processes that have already terminated, i.e. children of dead children?
[bpriya> yes, it is. Note that the process on which the construct is being called can itself be terminated, then the construct applies to its descendants - the same logic holds for an intermediate process in the sub-hierarchy that has terminated.]

Can you please clarify? Suppose process A spawns process B and B spawns C, and suppose process B is terminated first before A or C. You say that include_descendents on A should find C. Is this meant to imply that the implementation is obliged to keep the process handle for the terminated process B valid until after all its children have terminated, or is an implementation permitted to invalidate any handles to B while B still has surviving children? Would this be implementation-dependent?

Thanks,

John A

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.