commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar (JIRA)" <>
Subject [jira] Commented: (SCXML-112) Wrong behavior if event is triggered from EventDispatcher
Date Sat, 18 Jul 2009 19:02:14 GMT


Rahul Akolkar commented on SCXML-112:

I'm afraid externalizing the queue is best for the 0.x line.

Your feedback is appreciated. Some comments:

This involves years of code evolution, but to summarize quickly (not in any order):

 * SCXMLExecutor is the primary API for clients
 * SCInstance is the backing store for internal state
 * Status exposes the state clients most want to know about
 * SCXMLSemantics is the crux of the SCXML algorithm (extension point for users to have different
algorithm if and when it makes sense)

Much of that separation is useful IMO.

The #triggerEvents() behavior is different from a series of triggerEvent() calls, but that
was intentional when it was done (multiple active regions).

With many of the changes in the spec, its certainly on the cards to create a version of the
SCXMLExecutor for the next major line of development that internalizes the external events
queue that feeds the main loop for processing events (there'd be a inner loop for internal
events) and makes other tweaks to the algorithm as needed. But the idea won't be to drastically
change any API / contracts.

> Wrong behavior if event is triggered from EventDispatcher
> ---------------------------------------------------------
>                 Key: SCXML-112
>                 URL:
>             Project: Commons SCXML
>          Issue Type: Bug
>            Reporter: Ales Dolecek
>             Fix For: 1.0
>         Attachments:, test1.xml, test2.xml
> Method SCMLExecutor#triggerEvents is synchronized which is too naive way to ensure that
events are processed in order they arrive.
> Since the callback to EventDispatcher is made by thread that holds lock on SCMLExecutor
triggering event from the dispatcher allows this thread to re-enter the event handling.
> Note: This has nothing to do with multi-threading since there is only one thread.
> Simple queue might e sufficient but in multi-threaded application would make the first
thread to enter #triggerEvents process events from other threads queued while the method is
> Another approach might be to call EventDispatcher in separate thread,but it has it's
drawbacks too:
> a) changes single-threaded application into-multithreaded which might break assumtions
made by unaware user
> b) might start too many threads
> c) Java does not guarantee that threads waiting for lock will get it in same order as
they arrive => might result in non-deterministic behavior of SCXML interpretation
> Possible solutions would be:
> 1) add queue and allow the "first" thread server all events - might be just fine since
multi-threaded applications might create dedicate thread just for SCXML imterpretation
> 2) add queue and block threads after they queue event - so they "wait" until execute
their event become first in queue
> 3) factor out the queue event queue management and allow for "pluggable" strategy

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message