space88man left a comment (kamailio/kamailio#4800)
@abalashov - I absolutely hear your concerns - may I gently push What is the
purpose of this in the first place?
The goal is to consider the viability of a reactor style IO (by this I mean all
network is confined to one process including OpenSSL) while being well aware
that SIP processing has to be farmed out to all the workers.
For robust use of OpenSSL we have to trampoline all OpenSSL calls to a central
process - but this begs the question - why then not just do all network IO in
that process?
In fact you would observe that on the SSL read path today (tcp_main_threads >
0) **all** reads go through PROC_TCP_MAIN (via mtops and the `_tcond(...)`
macro) - so the socket clone in the TCP workers is used only for io_wait
notification and then we ask PROC_TCP_MAIN to do the real read. So we are
already doing all read IO in PROC_TCP_MAIN.
This is a strange asymmetry - on TCP we read in the worker and on TLS we read
in PROC_TCP_MAIN.
This PR takes this to its logical extreme by centralising all IO in
PROC_TCP_MAIN.
Each commit is designed to compile and run in fd-passing mode to cause no
regression in kamailio fd-passing mode.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4800#issuecomment-4856029540
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4800/[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!
