henningw left a comment (kamailio/kamailio#4539)
> @henningw
>
> > But I think that we probably should migrate the module completely to the
> > new approach, and not having a mix of new (trusted) and old (address) data
> > structures logic.
>
> Just in the meanwhile, before this rework is actually done, I suggest still
> to cover the existing solution with locks. Regarding the address table, I can
> update the commit and send additionally the coverage of address table with
> locks as well. I don't think this would be a big work.
>
> > About the duplicate entries, if they are not needed from a functional point
> > of view, we don't need to keep this capability IMHO.
>
> So if I understand this correct, we want the duplicate entries to be allowed,
> or did I misunderstand you?
If there is no need for having duplicate entries, I think they are not
necessary, we just need to document it.
> > As a side note, the permission module is probably a bit of a special case,
> > as its data its much more volatile as e.g. LCR or carrierroute. The
> > carrierroute module uses a simple approach with access locking and swapping
> > the old and new data structures. But as there are no concurrent reloads
> > done, this is of course fine.
>
> Exactly, and that's why it is so much important to cover the trusted and
> address tables with locks. We've been suffering from this drawback since a
> while.
>
> Let me know if I can add the address table rework here as well. Thanks.
For me its fine, maybe other developers want to add something as well. Just to
understand it correctly, the mentioned rework would be a smaller change for the
address, just adding some locking improvements? Or using basically the same
approach as for the trusted? For me the using the same approach would be fine
for both, as mentioned.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4539#issuecomment-3739334031
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4539/[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!
