Re: Proposal for sc_process_handle: AGREE

John,

  I'm not sure, whether this corner case can (or should be allowed to)
happen in an implementation. We could consider to to clarify the
invalidation of handles in that regard, though.

Some comments embedded below.

On 14/05/10 15:01, john.aynsley@doulos.com wrote:
>
> In writing up sc_process_handle::operator< I've hit another corner case.
> First I'll re-state the rules we agreed, but reworded slightly:
>
> (1) 2 valid handles are equal iff they are equivalent:
[snip]

> (2) a valid and an invalid handle are never equivalent:
[snip]

> (3) 2 invalid handles are equivalent iff they formerly pointed to the same
> process or no process object
[snip]

> Now the problem. When a process terminates, an implementation may chose to
> invalidate a handle or not:

  If I understand you correctly, you assume that an implementation may
invalidate only some of the handles of a terminated process. Is there
any reason for an invalidating implementation not to invalidate all
remaining handles?

  If we explicitly require, that either all or no handle is invalidated,
the corner case you describe can't happen, right?

> sc_process_handle p, q;
> p = q = sc_spawn(...);
>
> wait( p.terminated_event() );
>
[snip]
> else // 1 handle valid, the other not
> {
> sc_assert( p != q ); // One handle is invalid
> sc_assert( (p < q) || (q < p) ); ??????

I think, we need to go with

   sc_assert( !(a<b) && !(b<a) );

here, see below.

> }
>
> Here we have two handles that point to the same process object, but only
> one of them has been invalidated. By (2) they are not equivalent. By (3)
> they would become equivalent once again when the 2nd handle gets
> invalidated!

> I guess we go in one of two directions:
>
> * Either we keep (2), in which case two invalid handles are always
> equivalent and (3) is wrong. Effectively there is an equivalence partition
> for all invalid handles

Unfortunately, this is not possible. This would break/change the
relative ordering or handles when processes are terminated.

  As a result, the handle could NOT be used as a key within a map, since
the internal ordering of the map is required to be stable. Otherwise,
the lookup of a handle "behind" a now invalid handle could fail, leading
to duplicates in the map, etcetc.

> * or two handles are equivalent iff they point or pointed to the same
> process, in which case (2) need to be re-worded so it only applies where
> the handles point to different processes.

  Independently of the validity of handles, two handles shall be
equivalent, iff they point(ed) to the same or no process object.

> Personally I vote for the first option (keep (2)), because this is
> congruent with the fact that get_process_object() returns a null pointer
> for an invalid handle. Effectively all process handles with a null pointer
> are in the same equivalence partition.

  I would vote for the option to clarify the invalidation of processes
to only invalidate all handles of a given process at once. Although the
equivalence partition for invalid handles is nice, we need to
differentiate invalid handles to keep the ordering stable.

Greetings from Oldenburg,
Philipp

[snip]

-- 
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.