You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Johannes Wienke <jw...@techfak.uni-bielefeld.de> on 2014/08/29 12:39:11 UTC
[SCXML] onentry executable content parallel to further transitions
Hi,
we are currently evaluating commons scxml in the trunk version for our
purposes. On thing that confused us is the fact that transitions from a
state can already occur while that state's onentry executable content is
still processing. Hence, we end up with more parallelism than expected.
Is this the intended behavior?
From the SCXML specification I actually cannot find anything that either
allows or prevents this interpretation. So I am also curious how this
behavior is justified wrt. to specs.
Kind regards,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
Hi,
thanks for the feedback.
I could actually make this work by extending the executor and everything
seems to work fine.
Cheers,
Johannes
On 09/15/2014 04:32 PM, Ate Douma wrote:
> On 11-09-14 11:30, Johannes Wienke wrote:
>> On 09/09/2014 04:28 PM, Ate Douma wrote:
>>> On 08-09-14 18:59, Johannes Wienke wrote:
>>>> On 09/07/2014 10:31 PM, Ate Douma wrote:
>>>>> Actually, Commons SCXML already uses an event queue (one for internal
>>>>> events and one for external events).
>>>>> It is however the responsibility of separate client threads to only
>>>>> use
>>>>> the executor #addEvent methods and only use a single client thread for
>>>>> actual execution and event triggering on the state machine.
>>>>> The bug you encountered was in the Commons SCXML *internal*
>>>>> delivery of
>>>>> events which likewise (now) should use #addEvent but still used the
>>>>> #triggerEvent method instead. This should now be fixed.
>>>>
>>>> Ok, assuming I am always using addEvents to fill the event queue, what
>>>> is the correct pattern for a worker thread that then calls
>>>> triggerEvents()? As far as I can tell from the implementation, this
>>>> method returns immediately in case the queue is currently empty. Hence,
>>>> implementing something like
>>>> while (true) {
>>>> executor.triggerEvents();
>>>> }
>>>> should result in a loop wasting one CPU in case no external events need
>>>> to be processed? This sounds wrong to me.
>>>
>>> I think that is typically what you'll need to do, or else add some
>>> 'eventAdded' notification and coordination yourself (see below).
>>
>> Wouldn't it be much nicer from a user perspective if the executor could
>> offer something like waitForNextEvents() or
>> waitUntilEventsInExternalQueue()? Depending on the use case, this is
>> much easier to implement internally than externally.
>
> Yes, that might be possible to add.
> But note that the current implementation isn't 'done' yet and several
> aspects of the current specification with regards to the event IO
> processor [1] aren't
> completely implemented yet.
> That functionally was initially on my plan for milestone 3 in the
> roadmap [2], but I already discovered I need some of this earlier on,
> and I've already started on some further internal refactoring and
> enhancements in this area.
>
> But even when completed, such 'automatic' event coordination and
> execution still should remain an optional feature only to allow for
> other solutions where this coordination better be done within custom and
> domain specific client code.
>
> My goal anyway is to first get the event IO processing in place as
> required by the specification.
> But of course I'm also open for contributions and development support in
> general :)
>
> [1] http://www.w3.org/TR/scxml/#eventioprocessors
> [2]
> http://commons.apache.org/proper/commons-scxml/roadmap.html#Milestone_3:_External_communications_support
>
>
>>
>> Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
>> know all events that enter the state machine, or am I wrong? So I am
>> doomed to implement a busy waiting loop.
>
> Yes, in the current implementation you'll have to coordinate this yourself.
> It should be trivial though to extend the SCXMLExecutor for your purpose
> to get 'notified' about such #addEvent invocations.
>
>>
>>> The initiating thread creating/owning the executor/engine instance
>>> likely also should be responsible for managing the statemachine
>>> execution: instantiating and then starting with go(), continuing with
>>> triggerEvents(), and if needed resetting through reset().
>>>
>>> Other threads (as well as the 'owner' thread) can/should only add events
>>> to the queue through addEvent(Event), including threads dispatched from
>>> the engine itself.
>>>
>>> Only a single owner thread should 'trigger' subsequent engine
>>> processing.
>>> You can use executor.hasPendingEvents() to prevent the overhead of a
>>> trivial amount of CPU cycles, but executor.triggerEvents() with an empty
>>> queue will only impose a minimal overhead anyway.
>>
>> But if I know that there are currently no pending events, then I can't
>> do anything else then polling in a busy loop. Either I have to do this
>> quite often and just increase CPU load or with a larger sleep statement
>> I will add an unwanted delay in processing.
>
> Maybe you can try my suggestion above: extending SCXMLExecutor probably
> will allow for a trivial intermediate solution for this.
>
>>
>>> Because only the 'owner' thread does (and may do) the actual execution
>>> of the engine, you're guaranteeing, and protecting (yourself!), no
>>> concurrent statemachine processing will happen. The (current) executor
>>> intendedly does NOT enforce this (as you noticed) with synchronization
>>> blocks or otherwise.
>>
>> Ok, got it. Could you please fix up the respective FAQ entry that is at
>> least confusing in that respect:
>> https://commons.apache.org/proper/commons-scxml/faq.html#many-threads
>
> Done, thanks for pointing this out.
>
>>
>>> It remains that your owner thread will have to use some timer based
>>> triggering of the executor, but that is typical when dealing with
>>> multiple thread coordination/synchronization. Or else you could consider
>>> extending/intercepting the executor to 'notify' your owner thread when
>>> new events are added to the external queue.
>>> But with that you'll enter a domain specific implementation, not easily
>>> generalizable in Commons SCXML (although I'm happy to review patches
>>> ;) ).
>>
>> Is this really domain specific? Something simple as using notify on an
>> object available to clients whenever new events enter the external queue
>> would already be sufficient to implement a proper synchronization system
>> without busy waiting. And this would be a huge improvement several use
>> cases that I can imagine.
> Like I mentioned above, other use-cases might want/need to manage such
> event coordination themselves. So while it probably is feasible to add
> an optional and example wrapper solution handling this automatically on
> behalf of clients, it must leave room for other more domain specific
> solutions as well.
>
>
>>
>> Cheers,
>> Johannes
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Ate Douma <at...@douma.nu>.
On 11-09-14 11:30, Johannes Wienke wrote:
> Hi,
>
> On 09/09/2014 04:28 PM, Ate Douma wrote:
>> On 08-09-14 18:59, Johannes Wienke wrote:
>>> On 09/07/2014 10:31 PM, Ate Douma wrote:
>>>> Actually, Commons SCXML already uses an event queue (one for internal
>>>> events and one for external events).
>>>> It is however the responsibility of separate client threads to only use
>>>> the executor #addEvent methods and only use a single client thread for
>>>> actual execution and event triggering on the state machine.
>>>> The bug you encountered was in the Commons SCXML *internal* delivery of
>>>> events which likewise (now) should use #addEvent but still used the
>>>> #triggerEvent method instead. This should now be fixed.
>>>
>>> Ok, assuming I am always using addEvents to fill the event queue, what
>>> is the correct pattern for a worker thread that then calls
>>> triggerEvents()? As far as I can tell from the implementation, this
>>> method returns immediately in case the queue is currently empty. Hence,
>>> implementing something like
>>> while (true) {
>>> executor.triggerEvents();
>>> }
>>> should result in a loop wasting one CPU in case no external events need
>>> to be processed? This sounds wrong to me.
>>
>> I think that is typically what you'll need to do, or else add some
>> 'eventAdded' notification and coordination yourself (see below).
>
> Wouldn't it be much nicer from a user perspective if the executor could
> offer something like waitForNextEvents() or
> waitUntilEventsInExternalQueue()? Depending on the use case, this is
> much easier to implement internally than externally.
Yes, that might be possible to add.
But note that the current implementation isn't 'done' yet and several aspects of
the current specification with regards to the event IO processor [1] aren't
completely implemented yet.
That functionally was initially on my plan for milestone 3 in the roadmap [2],
but I already discovered I need some of this earlier on, and I've already
started on some further internal refactoring and enhancements in this area.
But even when completed, such 'automatic' event coordination and execution still
should remain an optional feature only to allow for other solutions where this
coordination better be done within custom and domain specific client code.
My goal anyway is to first get the event IO processing in place as required by
the specification.
But of course I'm also open for contributions and development support in general :)
[1] http://www.w3.org/TR/scxml/#eventioprocessors
[2]
http://commons.apache.org/proper/commons-scxml/roadmap.html#Milestone_3:_External_communications_support
>
> Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
> know all events that enter the state machine, or am I wrong? So I am
> doomed to implement a busy waiting loop.
Yes, in the current implementation you'll have to coordinate this yourself.
It should be trivial though to extend the SCXMLExecutor for your purpose to get
'notified' about such #addEvent invocations.
>
>> The initiating thread creating/owning the executor/engine instance
>> likely also should be responsible for managing the statemachine
>> execution: instantiating and then starting with go(), continuing with
>> triggerEvents(), and if needed resetting through reset().
>>
>> Other threads (as well as the 'owner' thread) can/should only add events
>> to the queue through addEvent(Event), including threads dispatched from
>> the engine itself.
>>
>> Only a single owner thread should 'trigger' subsequent engine processing.
>> You can use executor.hasPendingEvents() to prevent the overhead of a
>> trivial amount of CPU cycles, but executor.triggerEvents() with an empty
>> queue will only impose a minimal overhead anyway.
>
> But if I know that there are currently no pending events, then I can't
> do anything else then polling in a busy loop. Either I have to do this
> quite often and just increase CPU load or with a larger sleep statement
> I will add an unwanted delay in processing.
Maybe you can try my suggestion above: extending SCXMLExecutor probably will
allow for a trivial intermediate solution for this.
>
>> Because only the 'owner' thread does (and may do) the actual execution
>> of the engine, you're guaranteeing, and protecting (yourself!), no
>> concurrent statemachine processing will happen. The (current) executor
>> intendedly does NOT enforce this (as you noticed) with synchronization
>> blocks or otherwise.
>
> Ok, got it. Could you please fix up the respective FAQ entry that is at
> least confusing in that respect:
> https://commons.apache.org/proper/commons-scxml/faq.html#many-threads
Done, thanks for pointing this out.
>
>> It remains that your owner thread will have to use some timer based
>> triggering of the executor, but that is typical when dealing with
>> multiple thread coordination/synchronization. Or else you could consider
>> extending/intercepting the executor to 'notify' your owner thread when
>> new events are added to the external queue.
>> But with that you'll enter a domain specific implementation, not easily
>> generalizable in Commons SCXML (although I'm happy to review patches ;) ).
>
> Is this really domain specific? Something simple as using notify on an
> object available to clients whenever new events enter the external queue
> would already be sufficient to implement a proper synchronization system
> without busy waiting. And this would be a huge improvement several use
> cases that I can imagine.
Like I mentioned above, other use-cases might want/need to manage such event
coordination themselves. So while it probably is feasible to add an optional and
example wrapper solution handling this automatically on behalf of clients, it
must leave room for other more domain specific solutions as well.
>
> Cheers,
> Johannes
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
Hi,
On 09/09/2014 04:28 PM, Ate Douma wrote:
> On 08-09-14 18:59, Johannes Wienke wrote:
>> On 09/07/2014 10:31 PM, Ate Douma wrote:
>>> Actually, Commons SCXML already uses an event queue (one for internal
>>> events and one for external events).
>>> It is however the responsibility of separate client threads to only use
>>> the executor #addEvent methods and only use a single client thread for
>>> actual execution and event triggering on the state machine.
>>> The bug you encountered was in the Commons SCXML *internal* delivery of
>>> events which likewise (now) should use #addEvent but still used the
>>> #triggerEvent method instead. This should now be fixed.
>>
>> Ok, assuming I am always using addEvents to fill the event queue, what
>> is the correct pattern for a worker thread that then calls
>> triggerEvents()? As far as I can tell from the implementation, this
>> method returns immediately in case the queue is currently empty. Hence,
>> implementing something like
>> while (true) {
>> executor.triggerEvents();
>> }
>> should result in a loop wasting one CPU in case no external events need
>> to be processed? This sounds wrong to me.
>
> I think that is typically what you'll need to do, or else add some
> 'eventAdded' notification and coordination yourself (see below).
Wouldn't it be much nicer from a user perspective if the executor could
offer something like waitForNextEvents() or
waitUntilEventsInExternalQueue()? Depending on the use case, this is
much easier to implement internally than externally.
Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
know all events that enter the state machine, or am I wrong? So I am
doomed to implement a busy waiting loop.
> The initiating thread creating/owning the executor/engine instance
> likely also should be responsible for managing the statemachine
> execution: instantiating and then starting with go(), continuing with
> triggerEvents(), and if needed resetting through reset().
>
> Other threads (as well as the 'owner' thread) can/should only add events
> to the queue through addEvent(Event), including threads dispatched from
> the engine itself.
>
> Only a single owner thread should 'trigger' subsequent engine processing.
> You can use executor.hasPendingEvents() to prevent the overhead of a
> trivial amount of CPU cycles, but executor.triggerEvents() with an empty
> queue will only impose a minimal overhead anyway.
But if I know that there are currently no pending events, then I can't
do anything else then polling in a busy loop. Either I have to do this
quite often and just increase CPU load or with a larger sleep statement
I will add an unwanted delay in processing.
> Because only the 'owner' thread does (and may do) the actual execution
> of the engine, you're guaranteeing, and protecting (yourself!), no
> concurrent statemachine processing will happen. The (current) executor
> intendedly does NOT enforce this (as you noticed) with synchronization
> blocks or otherwise.
Ok, got it. Could you please fix up the respective FAQ entry that is at
least confusing in that respect:
https://commons.apache.org/proper/commons-scxml/faq.html#many-threads
> It remains that your owner thread will have to use some timer based
> triggering of the executor, but that is typical when dealing with
> multiple thread coordination/synchronization. Or else you could consider
> extending/intercepting the executor to 'notify' your owner thread when
> new events are added to the external queue.
> But with that you'll enter a domain specific implementation, not easily
> generalizable in Commons SCXML (although I'm happy to review patches ;) ).
Is this really domain specific? Something simple as using notify on an
object available to clients whenever new events enter the external queue
would already be sufficient to implement a proper synchronization system
without busy waiting. And this would be a huge improvement several use
cases that I can imagine.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Ate Douma <at...@douma.nu>.
On 08-09-14 18:59, Johannes Wienke wrote:
> Hi,
>
> thanks for the feedback work on this!
>
> On 09/07/2014 10:31 PM, Ate Douma wrote:
>> Actually, Commons SCXML already uses an event queue (one for internal
>> events and one for external events).
>> It is however the responsibility of separate client threads to only use
>> the executor #addEvent methods and only use a single client thread for
>> actual execution and event triggering on the state machine.
>> The bug you encountered was in the Commons SCXML *internal* delivery of
>> events which likewise (now) should use #addEvent but still used the
>> #triggerEvent method instead. This should now be fixed.
>
> Ok, assuming I am always using addEvents to fill the event queue, what
> is the correct pattern for a worker thread that then calls
> triggerEvents()? As far as I can tell from the implementation, this
> method returns immediately in case the queue is currently empty. Hence,
> implementing something like
> while (true) {
> executor.triggerEvents();
> }
> should result in a loop wasting one CPU in case no external events need
> to be processed? This sounds wrong to me.
I think that is typically what you'll need to do, or else add some 'eventAdded'
notification and coordination yourself (see below).
The initiating thread creating/owning the executor/engine instance likely also
should be responsible for managing the statemachine execution: instantiating and
then starting with go(), continuing with triggerEvents(), and if needed
resetting through reset().
Other threads (as well as the 'owner' thread) can/should only add events to the
queue through addEvent(Event), including threads dispatched from the engine itself.
Only a single owner thread should 'trigger' subsequent engine processing.
You can use executor.hasPendingEvents() to prevent the overhead of a trivial
amount of CPU cycles, but executor.triggerEvents() with an empty queue will only
impose a minimal overhead anyway.
Because only the 'owner' thread does (and may do) the actual execution of the
engine, you're guaranteeing, and protecting (yourself!), no concurrent
statemachine processing will happen. The (current) executor intendedly does NOT
enforce this (as you noticed) with synchronization blocks or otherwise.
It remains that your owner thread will have to use some timer based triggering
of the executor, but that is typical when dealing with multiple thread
coordination/synchronization. Or else you could consider extending/intercepting
the executor to 'notify' your owner thread when new events are added to the
external queue.
But with that you'll enter a domain specific implementation, not easily
generalizable in Commons SCXML (although I'm happy to review patches ;) ).
Regards, Ate
>
> Cheers,
> Johannes
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
On 09/09/2014 04:31 PM, Ate Douma wrote:
> On 09-09-14 11:20, Johannes Wienke wrote:
>> Hi,
>>
>> On 09/08/2014 10:07 PM, Martin Gainty wrote:
>>> StringTokenizer st = new StringTokenizer(event);
>>>
>>> int tkns = st.countTokens();
>>> TriggerEvent[] evts = new TriggerEvent[tkns];
>>> for (int i = 0; i < tkns; i++) {
>>> executor.triggerEvents();
>>>
>>
>> But then I have to implement a custom logic to restart that loop once
>> new events arrive after it finished once. Moreover, this doesn't look
>> thread-safe.
>
> Hi Johannes,
>
> Wrong list or did you intend to raise a question about the above?
> The context isn't clear to me and the code example confusing and not
> complete/correct either.
Got this as an answer to my question but it seems that answer did not
end up on the list.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Ate Douma <at...@douma.nu>.
On 09-09-14 11:20, Johannes Wienke wrote:
> Hi,
>
> On 09/08/2014 10:07 PM, Martin Gainty wrote:
>> StringTokenizer st = new StringTokenizer(event);
>>
>> int tkns = st.countTokens();
>> TriggerEvent[] evts = new TriggerEvent[tkns];
>> for (int i = 0; i < tkns; i++) {
>> executor.triggerEvents();
>>
>
> But then I have to implement a custom logic to restart that loop once
> new events arrive after it finished once. Moreover, this doesn't look
> thread-safe.
Hi Johannes,
Wrong list or did you intend to raise a question about the above?
The context isn't clear to me and the code example confusing and not
complete/correct either.
Ate
>
> Cheers,
> Johannes
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
Hi,
On 09/08/2014 10:07 PM, Martin Gainty wrote:
> StringTokenizer st = new StringTokenizer(event);
>
> int tkns = st.countTokens();
> TriggerEvent[] evts = new TriggerEvent[tkns];
> for (int i = 0; i < tkns; i++) {
> executor.triggerEvents();
>
But then I have to implement a custom logic to restart that loop once
new events arrive after it finished once. Moreover, this doesn't look
thread-safe.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
Hi,
thanks for the feedback work on this!
On 09/07/2014 10:31 PM, Ate Douma wrote:
> Actually, Commons SCXML already uses an event queue (one for internal
> events and one for external events).
> It is however the responsibility of separate client threads to only use
> the executor #addEvent methods and only use a single client thread for
> actual execution and event triggering on the state machine.
> The bug you encountered was in the Commons SCXML *internal* delivery of
> events which likewise (now) should use #addEvent but still used the
> #triggerEvent method instead. This should now be fixed.
Ok, assuming I am always using addEvents to fill the event queue, what
is the correct pattern for a worker thread that then calls
triggerEvents()? As far as I can tell from the implementation, this
method returns immediately in case the queue is currently empty. Hence,
implementing something like
while (true) {
executor.triggerEvents();
}
should result in a loop wasting one CPU in case no external events need
to be processed? This sounds wrong to me.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Ate Douma <at...@douma.nu>.
On 02-09-14 12:58, Johannes Wienke wrote:
> Hi,
>
> On 08/29/2014 12:39 PM, Johannes Wienke wrote:
>> we are currently evaluating commons scxml in the trunk version for our
>> purposes. On thing that confused us is the fact that transitions from a
>> state can already occur while that state's onentry executable content is
>> still processing. Hence, we end up with more parallelism than expected.
>>
>> Is this the intended behavior?
>>
>> From the SCXML specification I actually cannot find anything that either
>> allows or prevents this interpretation. So I am also curious how this
>> behavior is justified wrt. to specs.
>
> Following up on this: We have found a statement in the SCXML
> specification that disallows the current behavior. In section 4.10 the
> specification states:
>
> "Note that SCXML treats the executable content triggered by a transition
> as a single blocking operation and that no events are processed until
> all the executable content has completed. For example, when taking a
> transition into state S, the SCXML processor will not process any events
> or take any transitions until all <onentry> handlers in S have finished."
>
> This is definitely not the case right now when using multiple threads to
> trigger events.
Hi Johannes,
Please see my comments and fixes for SCXML-206 and SCXML-207.
The problems you were seeing were caused by erroneous and incorrect (internal!)
concurrent execution of the same state machine instance, which as you correctly
stated above is not allowed.
>
> From a design point of view: why do the client threads that trigger
> events directly process the whole event transition logic instead of
> using an internal event queue and a processing thread as proposed by the
> SCXML specification?
Actually, Commons SCXML already uses an event queue (one for internal events and
one for external events).
It is however the responsibility of separate client threads to only use the
executor #addEvent methods and only use a single client thread for actual
execution and event triggering on the state machine.
The bug you encountered was in the Commons SCXML *internal* delivery of events
which likewise (now) should use #addEvent but still used the #triggerEvent
method instead. This should now be fixed.
Regards, Ate
>
> Cheers,
> Johannes
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
Hi,
On 08/29/2014 12:39 PM, Johannes Wienke wrote:
> we are currently evaluating commons scxml in the trunk version for our
> purposes. On thing that confused us is the fact that transitions from a
> state can already occur while that state's onentry executable content is
> still processing. Hence, we end up with more parallelism than expected.
>
> Is this the intended behavior?
>
> From the SCXML specification I actually cannot find anything that either
> allows or prevents this interpretation. So I am also curious how this
> behavior is justified wrt. to specs.
Following up on this: We have found a statement in the SCXML
specification that disallows the current behavior. In section 4.10 the
specification states:
"Note that SCXML treats the executable content triggered by a transition
as a single blocking operation and that no events are processed until
all the executable content has completed. For example, when taking a
transition into state S, the SCXML processor will not process any events
or take any transitions until all <onentry> handlers in S have finished."
This is definitely not the case right now when using multiple threads to
trigger events.
From a design point of view: why do the client threads that trigger
events directly process the whole event transition logic instead of
using an internal event queue and a processing thread as proposed by the
SCXML specification?
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Johannes Wienke <jw...@techfak.uni-bielefeld.de>.
On 09/01/2014 09:23 AM, Ate Douma wrote:
> Great to see you looking into commons scxml!
> I've been away for a while on holiday so sorry for the late feedback on
> this and the other issues you reported. I haven't had time yet to dive
> into these but will look into them shortly.
Great! Thank you very much!
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
Re: [SCXML] onentry executable content parallel to further transitions
Posted by Ate Douma <at...@douma.nu>.
On 29-08-14 12:39, Johannes Wienke wrote:
> Hi,
>
> we are currently evaluating commons scxml in the trunk version for our
> purposes. On thing that confused us is the fact that transitions from a
> state can already occur while that state's onentry executable content is
> still processing. Hence, we end up with more parallelism than expected.
>
> Is this the intended behavior?
>
> From the SCXML specification I actually cannot find anything that either
> allows or prevents this interpretation. So I am also curious how this
> behavior is justified wrt. to specs.
>
> Kind regards,
> Johannes
>
Hi Johannes,
Great to see you looking into commons scxml!
I've been away for a while on holiday so sorry for the late feedback on this and
the other issues you reported. I haven't had time yet to dive into these but
will look into them shortly.
Regards, Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org