Change in osmo-mgw[master]: Add multithreading for the virtual trunk

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

Hoernchen gerrit-no-reply at
Mon Sep 13 17:15:52 UTC 2021

Hello Jenkins Builder, pespin, 

I'd like you to reexamine a change. Please visit

to look at the new patch set (#21).

Change subject: Add multithreading for the virtual trunk

Add multithreading for the virtual trunk

The idea is rather easy: do not disturb the code too much, so each
thread operates on a mgcp_trunk sub-trunk that has
- (it is) a mgcp_trunk structure just like the parent trunk
- some thread-specific information in struct per_thread_info
* this exists in the sub-trunk, as a SINGLE pointer (this_thread_info)
to the threads own info
- a different endpoint begin offset
- and different number of endpoint
- a private copy (!) of the mgcp_config structure that allows selective
updates of config settings during runtime using the vty

The thread-trunks doen't really know that they are not a full trunk, as
far as actual "mgw-operation" is concerned

Most of the other changes deal with the (t)alloc contexts to ensure
proper parent contexts that are not mixed between threads, the only
talloc that is threadsafe is the null context with disabled null
tracking, which is plain old malloc.

A parent trunk is configured using the vty/config as usual, so it also
has all the endpoints, but those are just not being used by anything,
all of the structs just exist to allow parsing and configuring, but the
updates are then also sent to the trunk threads. It contains the
thread_info array which has one per_thread_info struct entry for every
trunkthread of this trunk.

Communication betwen the main threads and the trunk thread(s) work by
sending messages through
- the mgcp msg queue for mgcp commands, which the thread then ansers by
writing to the socket, the queue back to the main thread is currently
- the cfg/vty command queue for vty commands and vty settings, that are
parsed and filtered by the threads own functions, the return queue to
the main thread is only being used to block it during vty show commands
that print in threads.

MGCP message handling is therefore split between a quick parsing in the
main thread to determine which endpoint (-> thread) should handle the
command and wrapping the command in a interthread queue buffer before
submitting it to one (or multiple) threads, and the usual processing
within the sub-trunk threads.

Multithreading is by default disabled unless "number threads" in the
config file exists.

Multithreading is disabled for e1 trunks due to the complexity of the
code and a lack of test coverage that reliably proves the absence of
threading related issues, so e1 is still being handled by the main
thread. Multithreading is also disabled for all trunks if osmux is
configured, also due to complexity and the fact that one osmux trunk is
limited to 256 calls due to the CID anyway, which can be handled within
one (main) thread.

That being said the code is ready to enable threads for all of that,
it's just not possible to prove that it will not implode at some point..

Change-Id: I31be8253600c8af0a43c967d0d128f5ba7b16260
M include/osmocom/mgcp/
M include/osmocom/mgcp/mgcp.h
M include/osmocom/mgcp/mgcp_endp.h
A include/osmocom/mgcp/mgcp_threads.h
M include/osmocom/mgcp/mgcp_trunk.h
M src/libosmo-mgcp/
M src/libosmo-mgcp/mgcp_e1.c
M src/libosmo-mgcp/mgcp_endp.c
M src/libosmo-mgcp/mgcp_protocol.c
A src/libosmo-mgcp/mgcp_threads.c
A src/libosmo-mgcp/mgcp_threads_vty.c
M src/libosmo-mgcp/mgcp_trunk.c
M src/libosmo-mgcp/mgcp_vty.c
M src/osmo-mgw/mgw_main.c
M tests/mgcp/mgcp_test.c
15 files changed, 1,208 insertions(+), 352 deletions(-)

  git pull ssh:// refs/changes/32/25432/21
To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I31be8253600c8af0a43c967d0d128f5ba7b16260
Gerrit-Change-Number: 25432
Gerrit-PatchSet: 21
Gerrit-Owner: Hoernchen <ewild at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin at>
Gerrit-CC: dexter <pmaier at>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list