Not the original developer of the memory managers, but, iirc, one of the
reasons for private memory manager was to avoid a multi-threading
related lock/mutex that is done by system malloc()/free(), which is not
necessary for pure multi-process application. I did not analyzed myself,
but I guess
> Thanks for the fixed pull request. @miconda probably want to review it. I
> just noticed two copied files from topoh regarding the call-id masking. Maybe
> it make sense to discuss if this could be avoided, but there might be no easy
> solution.
It will be hard to replace the CallID in the
@toharish pushed 1 commit.
8ab2395e37eb5017b1719814eb7da1ef802d8b27 Topos: CallID mask - update comment
--
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3323/files/622c6d45baa91ab322bab7dc97653ca32e468cfd..8ab2395e37eb5017b1719814eb7da1ef802d8b27
You are receiving this because
Thanks for the fixed pull request. @miconda probably want to review it.
I just noticed two copied files from topoh regarding the call-id masking. Maybe
it make sense to discuss if this could be avoided, but there might be no easy
solution.
--
Reply to this email directly or view it on
Call ID mask with a key similar to topoh insted of swaping with new ID. Call ID
masking is dome when a message is received from the upstream and unmasked
before sending towords upstream.
!-- Kamailio Pull Request Template --
!--
IMPORTANT:
- for detailed contributing guidelines, read:
Thanks, that's educational.
I assumed the original argument was performance-related. I just wasn't sure if
that was still (sufficiently to be important) true. After all, lots of
SER/OpenSER design decisions in the early 2000s made the most sense then, like
inventing own imperative scripting
Thank you. I'll try to create a testing situation around this.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3318#issuecomment-1372373543
You are receiving this because you are subscribed to this thread.
Message ID:
Just to add, this paper gives a lot of benchmark results for different
allocators and two glibc versions:
https://adms-conf.org/2019-camera-ready/durner_adms19.pdf
It seems that even in 2019 using a special allocator can have some benefits for
certain workloads.
Cheers,
Henning
--
Henning
(adding sr-dev)
Hi Alex,
the memory allocator of glibc was not really efficient regarding the particular
needs of a SIP server (allocation of many small string objects).
That has probably improved in the last years, also system performance just got
much faster.
Other programs/tools also use
Probably the developer thought only one of the tables are used in a Kamailio
instance, they kind of overlap a lot in purpose and functionality. Personally I
use only address table, I don't think I ever initiated a Kamailio deployment
using the trusted table.
Anyhow, because this kind of
Module: kamailio
Branch: master
Commit: 10c0c1889be5b1aed27a41a87c45b5c5e8a92cf3
URL:
https://github.com/kamailio/kamailio/commit/10c0c1889be5b1aed27a41a87c45b5c5e8a92cf3
Author: Kamailio Dev
Committer: Kamailio Dev
Date: 2023-01-05T15:01:40+01:00
modules: readme files regenerated -
Module: kamailio
Branch: master
Commit: 09bbe96a32f70ff7328eac431ea2efb48a3a8175
URL:
https://github.com/kamailio/kamailio/commit/09bbe96a32f70ff7328eac431ea2efb48a3a8175
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2023-01-05T15:00:17+01:00
permissions: docs -
Module: kamailio
Branch: master
Commit: 5d9ed676dad76729253ee734d20a805e2a0dcc5c
URL:
https://github.com/kamailio/kamailio/commit/5d9ed676dad76729253ee734d20a805e2a0dcc5c
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2023-01-05T14:59:37+01:00
tls: docs - note that
This is a great idea, also much easier as implementing it for every module.
Thanks,
Henning
-Original Message-
From: Daniel-Constantin Mierla
Sent: Wednesday, January 4, 2023 10:31 AM
To: sr-dev@lists.kamailio.org
Subject: [sr-dev] git:master:a71a6ed6: core: rpc - support for
> > > you included several unrelated commits for rtpengine as well. They seems
> > > to come from some merge action. Could you ple
>
> > Rtpengine was a different commit 4 months ago and it is already merged
>
> Please have a look to your commits included in this PR, as visible above. It
> in
Closed #3322.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3322#event-8159929337
You are receiving this because you are subscribed to this thread.
Message ID: ___
Kamailio (SER) - Development Mailing
Module: kamailio
Branch: master
Commit: d0b1d6cc15b1c4e98ac65e4d90c6f53f2da63218
URL:
https://github.com/kamailio/kamailio/commit/d0b1d6cc15b1c4e98ac65e4d90c6f53f2da63218
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2023-01-05T13:16:27+01:00
permissions: set the
Module: kamailio
Branch: master
Commit: bb0c08676ccf33fabd7a0de27129c2ad98ac2208
URL:
https://github.com/kamailio/kamailio/commit/bb0c08676ccf33fabd7a0de27129c2ad98ac2208
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2023-01-05T12:22:31+01:00
core: replaced
Module: kamailio
Branch: master
Commit: a49dcf0cee005585222dacaa25d5d97e4934245e
URL:
https://github.com/kamailio/kamailio/commit/a49dcf0cee005585222dacaa25d5d97e4934245e
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2023-01-05T11:15:07+01:00
tls: set
19 matches
Mail list logo
