W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

RE: proposed new definition of preemption

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 26 Feb 2013 16:06:43 +0000
To: David Junger <tffy@free.fr>, "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281023468@GENSJZMBX03.msg.int.genesyslab.com>
Ok that's fine.  I think that all implementations will end up with something that is more efficient, but harder to explain, than the intersection of exit sets.  (The version based on transition 'types' was my attempt at such a definition.)

-          Jim

From: David Junger [mailto:tffy@free.fr]
Sent: Tuesday, February 26, 2013 11:01 AM
To: VBWG Public (www-voice@w3.org)
Subject: Re: proposed new definition of preemption

Le 26 feb 2013 à 14:39, Jim Barnett a écrit :

On your third point, I think that you are right that targeted transitions will conflict if one's source state is a descendent of the other's, but that is not the only condition under which they conflict.  Consider a parallel element P with children S1, S2, and put transitions in S1, S2 that both exit P and go to different remote states (i.e., ones that cannot be simultaneously active).  The transitions in S1, S2 conflict, but neither's source state is a descendent of the other's.

Indeed, but in that case S2's source state will have been exited by S1's exit step, and I meant that the preemption based on source states' hierarchical relation would fix the method relying on source states being exited (you pointed out yourself that it didn't work all the time) rather than replace it. Since computing the hierarchy between tree nodes is very fast, and then testing whether a state is still active is just one operation, the result is a simple, basically linear algorithm that doesn't need compilation to quickly determine which transitions to take.

I think the exit set definition is "simpler" (not to implement, but to read) so I don't mind if it goes in the spec. The problem with the approach described above is that it effectively does what we define as "preemption" in two separate parts of the code (first remove hierarchical conflicts, then remove other conflicts during the exit step).

Received on Tuesday, 26 February 2013 16:07:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:43 UTC