John,
On 18/05/10 22:17, john.aynsley@doulos.com wrote:
>
> It seems to me that the one key rule is:
>
> * Two initialized handles are equivalent iff each handle currently
> (if still valid) or previously (if invalid) is associated with the same
> process instance as the other handle, and neither is equivalent to
> any uninitialized handle.
>
> In this rule, either, one, or both handles may be invalid, and nothing
> is said about the equivalence of two uninitialized handles.
Agreed.
Although the term "uninitialized handle" is not very precise, since
the sc_process_handle class has a default constructor. So from a C++
point-of-view all handles are somehow initialized, maybe
default-initialized to an invalid/empty handle. Maybe we can use the
term "empty handle" for this special case?
> Further to that, there is a piece of advice:
>
> * If you assign a handle that is stored in a map, you had better
> update the map following the assignment, or it will be stale.
I don't understand this. What is the perceived pitfall here (e.g.
compared to a map with raw pointers as keys)?
> If you store two uninitialized process handles in a map, I cannot see a
> reason why they should be equivalent or not equivalent, provided neither
> is equivalent to any initialized handle, and provided their order is
> stable.
Yes, both is theoretically possible.
> We should have a rule rather than it being implementation-defined, but
> I don't see that it matters which rule we chose, does it?
What is the value of "sc_process_handle() < sc_process_handle()"?
Should it be constant? deterministic? random()? unspecified? ;-)
I would prefer (which makes empty handles equivalent):
sc_assert( sc_process_handle() < sc_process_handle() == false );
Having a less restricted behaviour for this, IMHO requires additional
wording for copy constructor/assignment operator. Because copies of
handles should of course be equivalent (even for empty ones):
sc_process_handle p;
sc_assert( sc_process_handle(p) < p == false );
> I suppose it would affect the size of the map if there
> were a lot of uninitialized handles.
Exactly. It depends on the answer to the above question... :-)
> Regarding the timing of handle invalidation following process
> termination, given that it is implementation-defined in 1666-2005
> (presumably to give implementors scope for optimization), I see no
> reason to start imposing constraints on invalidation now. But I don't
> really care if there is a compelling reason.
Yes, we don't need to specify this due to operator<, if we define the
equivalence independently of the validity.
Actually, the point in time of the invalidation relative to process
termination should not be restricted. BUT, invalidation itself should
be consistent. Given two valid, equal handles, once one of them becomes
invalid the other one should be invalid as well:
sc_process_handle p,q;
// two valid, equal handles
p = q = sc_spawn( ... );
// ... some time later ...
// OBSERVE invalidation of one of the handles
sc_assert( p.valid() == false );
// afterwards: OBSERVE a valid handle to the terminated process
sc_assert( q.valid() == true ); // Huh?!
We KNOW, that both handles once pointed to the same process, but we
suddenly can't use the handles interchangeably any more. This seems to
be very dangerous and counter-intuitive.
Greetings from Oldenburg,
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.Received on Wed May 19 07:31:48 2010
This archive was generated by hypermail 2.1.8 : Wed May 19 2010 - 07:31:51 PDT