[question] thread safety

[redboltz]

According to the following documentation, sml can be thread safe. http://boost-experimental.github.io/sml/overview/index.html#thread-safety

It's nice!

If I choose std::recursive_mutex for the threading policy, I guess that I can call process_event in the action handler.

sml::sm<example, sml::thread_safe<std::recursive_mutex>> sm;

If I choose std::mutex, sml will be dead locked at the second process_event form the action handler?

By the way, Boost.MSM provides enqueue_event().

Here is the document about that.

---

http://www.boost.org/doc/libs/1_62_0/libs/msm/doc/HTML/ch03s05.html#d0e2331

Enqueueing events for later processing

Calling process_event(Event const&) will immediately process the event with run-to-completion semantics. You can also enqueue the events and delay their processing by calling enqueue_event(Event const&) instead. Calling execute_queued_events() will then process all enqueued events (in FIFO order). Calling execute_single_queued_event() will execute the oldest enqueued event.

You can query the queue size by calling get_message_queue_size().

---

Does SML have these kinds of function?

[krzysztof-jusiak]

Yea, the second process (triggered via transition table-process) will cause a dead lock in case of mutex, which is unfortunate. I'm planning to change the process on the transition table to queue_event instead so that this issue could be avoided. Boost.MSM events queue is the way to go here and I'm going to implement that soonish. However, it's not available yet :(

I'll keep this issue open to track the implementation. Most likely, it will be done next week as I'm off for a few days.

[redboltz]

Thank you for the quick response. I can use std::recursive_mutex for multi-threading sml code. It satisfies my purpose, so far. Anyway I will wait update :)

[CodingPapi]

@krzysztof-jusiak hi, is there any update on this issue? thanks