This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Andreas Eversberg andreas at eversberg.eu> > * You directly call rsl_handle_release and can get ahead of itself. This > is a problem for: > > > if (deact_sacch == SACCH_DEACTIVATE) > rsl_deact_sacch(lchan); > rsl_release_sapis_from(lchan, 0, RSL_REL_LOCAL_END); > > /* TODO: start T3109 now. */ > rsl_lchan_set_state(lchan, LCHAN_S_REL_ERR); > > So with your change rsl_handle_release will be called when lchan->state > is not set to LCHAN_S_REL_ERR yet. > you are right. i have no solution for this problem yet. at osmocombb/mobile i use queues to solve these kind of problems. whenever i want to handle something after osmo_select_main() was processed, i write into a specific queue. the main loop will call all dequeue functions in a loop, until all queues are empty and then continue with next osmo_select_main() call. one solution for handling the missing RELease CONFirm from BTS could be a timer with 0 duration. the timer will be handled right after the process you showed above is done. this timer could also have a duration of 1 second. if the BTS acutally sends a confirm, the timer could be stopped. this way it would also work with BTS firmwares that actually send a confirm.