<p style="white-space: pre-wrap; word-wrap: break-word;">Async events would introduce pretty large complexity, and they would not solve the use-after-free problems.</p><p style="white-space: pre-wrap; word-wrap: break-word;">What these FSM patches do is remove complexity.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The beauty of it is that plain function calls benefit from it just like other FSM instances do.</p><p style="white-space: pre-wrap; word-wrap: break-word;">This is another instance of a feature that should have been enabled from the start, for very simple and straightforward reasons: when an FSM instance terminates, how do I check whether it has terminated? It is a paradox, because when the instance has terminated, I am not allowed to access its memory anymore (to check a flag or fi->state), because I would access freed memory. I have had to solve countless crashes because of this fundamental problem.</p><p style="white-space: pre-wrap; word-wrap: break-word;">This problem has been present right from the start of osmo_fsm, and for ages I have been fighting these problems with super complex structures of conditionals that skip cleaning up or not, depending on what might have happened or some specialized flags. That was super annoying BF hell. A lot of wasted time.</p><p style="white-space: pre-wrap; word-wrap: break-word;">If instead deallocation is deferred, we can easily check a flag like fi->proc.terminating or fi->state without risking a use-after-free. We can also implicitly stop event dispatch and state transitions and duplicate term. We can solve this entire class of cleanup problems with one elegant solution, which fixeria came up with, btw, which I am super thankful for.</p><p style="white-space: pre-wrap; word-wrap: break-word;">For me this and osmo_fsm_set_term_stops_actions() are a game changer in implementing FSM cleanup, all I see is a massive bunch of complexity falling away and leaving behind very simple cleanup logic. I really cracked my head on this stuff over the past years, and now all of it is just solved without adverse effects. So I am actually surprised that you guys see it as kludge and complexity or nuclear weapons on flies, it is the opposite. It is a super simple solution for huuuuugely complex problems, not one, but all of them, in one fell swoop.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Maybe you guys don't appreciate it as much as I do, since I believe I am the person that has spent the most time connecting various FSM instances running in complex relations to each other. Even in plain parent/child associations, I needed the osmo_fsm_term_safely() to avoid use-after-free, which happens as soon as both a parent and a child want to trigger collective term. (If I could go back, I would actually undo osmo_fsm_term_safely() and rather use this more elegant solution instead.)</p><p style="white-space: pre-wrap; word-wrap: break-word;">If you doubt the necessity of solving these problems, just switch off osmo_fsm_term_safely() and this patch, and try to solve the problems in fsm_dealloc_test.c manually, see libosmocore/tests/fsm/.</p><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/15677">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/libosmocore/+/15677">change 15677</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/libosmocore/+/15677"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: libosmocore </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 </div>
<div style="display:none"> Gerrit-Change-Number: 15677 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-CC: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-CC: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 29 Oct 2019 16:14:03 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>