On 18/03/10 12:22, john.aynsley@doulos.com wrote:
> Whoops. If a dead process object gets reincarnated as another process with
> another handle, haven't we got a problem? The new process would have
> equivalent ordering to the dead process, no?
Hmmm, I think this shouldn't be a problem. At least, it has to be
consistent with operator==, right?
If it's really the same process object, then the handles would've been
valid all the time (even though temporarily terminated). New handles,
that still compare equal to the old ones are naturally ordered in the
same way, as they still point to the same (now maybe reincarnated)
process object.
If its a new process object (with new handles comparing unequal to the
old handle), then a different ordering is both expected and required, I
think.
> From: john.aynsley@doulos.com
[snip]
> Date: 18/03/2010 11:09
[snip]
> Agreed. Cool. Swap too.
Glad to hear. :-)
> I would probably want to spell out "strict weak ordering" and "collation
> order" rather than relying on familiarity with the C++ standard.
Ok. I can try to provide an updated/more explicit wording. But this
will have to wait until next week, as I'm quite busy (and out of
office) until Tuesday, I suppose.
> Just to be concrete, the following implementation...
>
> bool operator< (const sc_process_handle& r) const {
> return this->get_process_object() < r.get_process_object();
> }
>
> would work fine, provided the implementation left the dangling pointers
> unchanged following invalidation, right?
Exactly.
Greetings from Oldenburg,
Philipp
> (But I agree that the
> implementation should be free to implement "strick weak ordering" however
> it likes, and I agree the order could vary from run-to-run.)
[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.Received on Thu Mar 18 11:12:36 2010
This archive was generated by hypermail 2.1.8 : Thu Mar 18 2010 - 11:12:38 PDT