Proposal for sc_process_handle (was: Re: Identifying quickly what is the current process)

John, all,

since you asked for more solid proposals regarding the operator< issue
on the sc_process_handle, I tried to put up a possible wording.

  Additionally, I would like to see the addition of a "swap" function,
which is widely used in modern C++ designs. Especially if the handle is
not guaranteed to be a small wrapper around the process pointer (and may
get invalidated upon process termination, etc.), this could be beneficial.

Please note, that my current proposal does _not_ require a reproducible
ordering. Comments on that are below.

On 15/03/10 17:38, Stuart Swan wrote:

> Also - if possible I'd like operator< to work reproducibly the same
> way on different implementations and platforms.

Sure, this _would_ be possible, but seems too costly, IMHO. I fail to
see any use case for this, anyhow. Stuart, in which scenario do you
envision a need for this deterministic ordering?

  Moreover, even process names are currently not strictly reproducible
across implementations (since elaboration order is not strictly defined
and thus automatically generated names may differ). So there may be
more changes needed to actually guarantee this.

  Without specifying the exact ordering, this operator can easily be
implemented in constant time, which is a Good Thing, I think.

> Since operator< will be called quite rarely, I think just using the
> full hierarchical name of the process is sufficient.

Why is it called rarely?

> On first call, we copy the name from the process object to the
> handle, so that if the process terminates then subsequent calls to
> operator< still work and return the same result.

  This would increase the cost of using handles quite significantly.
AFAIU, handles are meant to be light-weight and cheaply copyable.

  IMHO, it should be up to the implementation, how to keep the ordering
valid after the underlying process has terminated. For an invalidating
implementation, a simple boolean flag for the validity would be enough,
too. Then you can still use the (now potentially dangling) process
pointer for the operator< implementation.

If we do not define the exact ordering, something like the following
additions to section 5.6 could be sufficient:

----
[5.6.2 Class definition]
Add the following lines to the class definition:
  void swap( sc_process_handle& );
  bool operator< ( const sc_process_handle& ) const;
[5.6.5 Member functions]
Add the following paragraphs to the member function descriptions:
bool operator< ( const sc_process_handle & rhs ) const;
  The less-than operator shall return true, if and only if *this
  precedes rhs in the implementation's collation order.  The ordering
  of process handles shall define a strict weak ordering on the
  underlying process instances.
    The implementation is obliged to keep the relative ordering of a
  handle unchanged, even if it gets invalidated after the termination
  of the underlying process instance (see function terminated).
  NOTE -- The exact collation order is implementation-defined and may
          differ from run to run.
void swap( sc_process_handle& );
  The swap function shall swap the underlying process instances
  of two handles.
----
Remarks:
 - The wording for operator< makes use of the "strict weak ordering"
   terminology from the C++ standard (25.3/p4).  Maybe we need to
   add a reference here.
 - Should we add an example to the swap function description?
   Something like:
   sc_process_handle a, b = sc_get_current_process_handle();
   sc_assert( ! a.valid() );
   a.swap( b );
   sc_assert( a == sc_get_current_process_handle() && !b.valid() );
What do you think?
Philipp
-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
R&D Division Transportation | FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.