RE: [tamie] Intertwining catch with posted events.

In the following I use the term “monitoring” to indicate that scripts are being executed as events are being recorded, while “testing” indicates that scripts are run after all events (except posted events) have been recorded. Monitoring and testing are kinds of execution contexts (for scripts).

As I understand it, “catch” statements do not themselves block indefinitely, whether the execution context is monitoring or testing, because there can always be a time out for “trying” the operation. This time-out is related to the actual time of running the script.

<JD> yes, execution time could be "virtual" i.e. simulate a past execution by running a time-cursor that represents a virtual present time.

However, it may be that the time for “trying” can be omitted. (The wiki description of “catch” appears to allow omission.) In that case, there is always a window for looking for an event, and when the event board contains a span of relevant events whose overall duration exceeds the window value, the board will not be getting additional events within that window. So the board is window-complete for events of relevance and can time out, even if an event being caught is not present in the blackboard.

<JD> yes, the CATCH will always time-out and complete one way or the other.

So it appears that whether monitoring or testing, a single threaded script execution environment will not block indefinitely because eventually the catch statement will time out for one of two reasons provided above.

While a “hang” of the thread remains possible (because looping is allowed), it does seem that a blocking hang will not be a problem for single threaded execution environments because of catch.

However, adding the posting of events to communicate between scripts can create issues for multi-threaded environments.

Suppose thread A has catch A that is waiting for an event that can be posted from a script running in thread B. Thread B could have its execution delayed so that it fails to post an event before thread A’s “trying” time out arrives. In that case thread A misses the event from B that it was to catch. [The multi-threading introduces a kind of indeterminism into the outcome of the script execution for situations involving post of events.]

But why would this “missing the event” impact multithreaded and not impact single-threaded execution environments? If the sequence of instructions in thread A is run before all instructions of thread B, and A is waiting for an event that will be posted by B, then A will have finished before B runs and not see the event B posts. Presumably no one would write a script that waits for an event that only can be produced after the script finishes! So the single-threaded case is categorized under “silly user error is always possible”!

Back again to multithreaded execution environments-- how can threads be synchronized appropriately so that when posted events can be produced by a separate thread, a thread waiting for such “synthetic” events does not complete until the other posting thread has completed? I think it will take some more investigation to see how to use posting events to coordinate script actions in a multithreaded environment so that various race conditions do not produce unexpected results.

<JD> Right. But these concerns could be left to a proper implementation design, as our scripting does not seem to introduce new problems in this area?

A concurrent execution model a little smarter than "do A then do B" would take advantage of "waits" induced by CATCH, to pass the control to other threads in the same way as multitasking releases the CPU at each I/O.

So when A is waiting on its CATCH, B would execute until it is blocked itself. Etc. Of course that is not enough.

The next level in sophistication would be: (a) a waiting thread gives control to other threads, (b) as soon as a new event is posted by one of the "active" threads, we check if it can be caught by the waiting threads.

Classical deadlock situations may occur (2 threads or more waiting for each-other events) that we may not be able to avoid though.

Intuitively though: a good execution model is one that gets as close as possible from the "ideal real time" concurrency, where there is a separate concurrent processor allocated to each thread. A convenient approximation of this seems to be that for each event op (CATCH or POST - and I include "sleep" as a form of CATCH) that is executed, the processor is given to the thread whose time-cursor is most lagging behind. So if your A and B start virtually at time t1, and if A.catch occurs a time t1+d, then B is obviously next in line as it is still at t1.

It seems that in the Testing case (with all events already in store) we'll need to care about this if we want to provide something like a reference (XSLT) implementation.

A simple example and the start of an analysis from the Event Processing community (EP or CEP) can be found at:

http://epthinking.blogspot.com/2008/10/more-on-semantics-and-race-conditions.html

tamie message