rfuchs left a comment (kamailio/kamailio#4809)
> > Since AFAICT the only thing writing to the permissions and the dispatcher
> > tables is the reload function, which always constructs a brand new table
> > and then switches them out, I would suggest to add a reference count to the
> > tables in question. That would allow arbitrary concurrent read access while
> > also making simultaneous reloads safe, with minimal added overhead. It
> > would also make the current (unsafe) double-buffering and rate-limiting
> > approach obsolete. Willing to implement if acceptable.
>
> Reference counters could be a good option, but having only a single table can
> lead to (rather long) blocking, in the way that when a reload is triggered,
> SIP workers that already started have to finish their walk through records to
> dereference the table, while other SIP workers that want to start have to be
> stopped and wait for the reload to finish.
>
> Keeping two (or even more) tables can be good for many reloads triggered in
> short time, having an active table and a list of old tables that are kept
> till reference counter gets to 0.
There would still be two (or more) tables during a reload, but globally visible
would ever be only a single pointer to one. The reload function would construct
a new table in local scope, fill it with data, and once finished will swap out
the global pointer, dropping a reference to the old table. Any workers still
reading the old table would hold a reference to it (in their local scope) and
would be safe, and the old table would be freed only once the refcount drops to
zero.
The only downside in such a simple approach would be that if a concurrent
reload happens, the freeing of the old table would happen in a worker process
and not in the RPC process. (If that's a concern, then the freeing of an
orphaned table could also be delegated to an RPC process with some additional
instrumentation, whenever the next reload happens.)
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4809#issuecomment-4915829206
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4809/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
