One use of constraints is to listen to a filtered stream of events. Since the code that the constraints use to check EVENTs or ENTITIYs is code that (normally) would trigger events, this could lead to a disastrous infinite loop, where a CONSTRAINT checking an EVENT could create an EVENT, that would be checked by a CONSTRAINT, generating an EVENT and so forth into infinity. This is, of course, not the desired behavior. For this reason there are in the kernel two classes to deal with this:
Any CONSTRAINT that extends this CONSTRAINT, will implement a describe method. When anything using the CONSTRAINT calls the accepts, the accepts method in AbstractEntityConstraint will temporarily disable the current thread's ability to trigger events, check the describes method, reset the event-triggering state of the thread, and return the appropriate value. See figure 2.2 for a visual account of this process.
This CONSTRAINT works exactly as above, but with EventConstraints.