Hello Jenkins Builder, pespin,

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

https://gerrit.osmocom.org/c/osmo-mgw/+/25432

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

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 answers by writing to the socket, the queue back to the main thread is currently unused. - 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..

Depends: libosmocore Id8405099e6b316c2e14fb0c9b3c5e80a68a91277

Change-Id: I31be8253600c8af0a43c967d0d128f5ba7b16260 --- M include/osmocom/mgcp/Makefile.am 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/Makefile.am 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,161 insertions(+), 353 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/32/25432/38