The engineUpdate() code is essentially an FSM evaluator. One of the things that can happen while evaluating is reportEvent(), which in turn dispatches to client code.
There are paths from client code that directly trigger calls to engineUpdate(). This means that engineUpdate() can be invoked recursively if clients call those APIs from onEvent() or the new equivalents. Based on my testing, that can be a bad thing, depending on the whether the recursion is effectively a tail-recursion.
The current design of engineUpdate() is not a fully elaborated FSM; instead, callbacks trigger other code that may or may not trigger calls to engineUpdate(). Clearly, in simple cases things are correct, but in more complex cases (such as the certification tests), it becomes quite a burden on the client. Instead, engineUpdate() and the APIs should be designed to be forgiving; if you call things from your event handler at an inconvenient time, processing should be deferred to a later time. Luckily, this is unlikely to break any client code, but rather make it more robust.
At the same time we'll want to address #240.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4