RE: Identifying quickly what is the current process

Stuart, Jerome,

Nah, the copy ctor is public but it duplicates the process handle. You are
permitted multiple process handles to the same process.

But my answer to Jerome is to simply use the value returned from
sc_process_handle::get_process_object() , which is the address of the
process object itself, as the unique id. (You can then use std::map to get
an integer id, if you like.)

John A

From:
Stuart Swan <stuart@cadence.com>
To:
Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Cc:
Eric PAIRE <eric.paire@st.com>, "'Laurent MAILLET-CONTOZ'"
<laurent.maillet-contoz@st.com>
Date:
10/03/2010 22:04
Subject:
RE: Identifying quickly what is the current process
Sent by:
owner-systemc-p1666-technical@eda.org

Jerome-

I may be mistaken, since it has been a few years since I dug into this
code,
but I think you may be able to use the sc_process_handle object itself as
the
unique identifier that you seek. I think the copy ctor is public, and the
object
itself is very lightweight so it does not consume much time or space to
copy it.

One issue with having the integer ID that you propose at bottom is whether
such
integer IDs would ever be recycled when the original process dies. With
the process_handle
approach above there is no such issue. Plus, you get easy access to the
process name, etc.
And, with the process control extensions that Cadence has proposed for
this update, you get
additional functionality like kill, etc.

Let me know if this doesn't work for you.

Thanks
-Stuart

>-----Original Message-----
>From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf
>Of Jerome CORNET
>Sent: Wednesday, March 10, 2010 6:16 AM
>To: systemc-p1666-technical@eda.org
>Cc: Eric PAIRE; 'Laurent MAILLET-CONTOZ'
>Subject: Identifying quickly what is the current process
>
>All again,
>
>there are various situations where knowing what is the current process
>(if any) is important.
>For instance, one could want to compute statistics on a per SystemC
>process basis.
>The current norm standardized very useful APIs to get information about
>what is the current process, with sc_get_current_process_handle() and
>the sc_process_handle
>class.
>
>However, there is no convenient and efficient way to understand what is
>the current process
>compared to previous invocations of sc_get_current_process_handle(). As
>an example, let us
>imagine I want to gather statistics about all processes in the
>simulation. I would build an array
>whose index would be a "process identifier" and that would contain my
>"per-process" stat.
>
> - The const char * returned by name() in sc_process_handle could be a
>candidate to this "process identifier",
>but this is rather inefficient (many string compare to understand in
>which array index I already
>stored my stat.,
>
> - The adress of the sc_process_handle object cannot be taken as
>"process identifier" as one could
>have two different sc_process_handle representing the same process
>information,
>
> - There is also the operator== that allows to compare whether two
>process handle actually represent
>the same process's information. This would oblige to use the
>sc_process_handle object itself (and not
>a pointer to it) as the process indentified, which is not very
>convenient, especially if you want to use a STL container
>for the array (I guess that the copy constructor is private, which means
>no std::vector, etc., etc.).
>
>So we want to propose to add a method to the sc_process_handle class,
>that could be as below:
>
>uint64_t id() const;
>
>and that could return a unique integer identifier associated with the
>process. Hence, it would be
>possible to retrieve and compare very quickly in what is the current
>process.
>
>Jerome Cornet
>STMicroelectronics
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

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