On Nov 15, 2024, at 8:17 AM, Francis Augusto Medeiros-Logeay <r_f@med-lo.eu> wrote:
Before reading your message, I tried with threads, and it seemed better to handle my specific situation, but I don’t want to do anything that’s non-kosher here. I just thought it was ok to use threads here due the reference to threading.local() on the documentation.
You can use threads in python, but they won't help. The server has it's own thread pool. Each request is processed through one thread at a time, until it finishes. This means that if the Python module calls a blocking API, then it blocks that thread. Adding more Python pthreads won't help, because the main *FreeRADIUS* thread is blocked.
That’s the thing: I have the default configuration, which is five servers. But even a second connection doesn’t execute concurrently. If the first hangs, the second still waits. Is there any configuration for the python module to make it more compliant to this?
If you're using the python3 module, it will create one Python interpreter, but will create sub-interpreters for each FreeRADIUS thread. I suspect the issue may be either that the Python API you're using has a global lock, or else you're running into the main Python lock. So... this is really a Python problem. TBH, unless the *only* way to interact with that API is through a Python library, you're better off just using the basic server features. We've done many, many, installations, and the only time we need Perl / Python is when we have to use an external API, and the only tools available are Perl / Python.
What I am trying here is to emulate a bit the behaviour of the NPS radius, which handles push notifications. Those are blocking, so I don’t want to return `OK` before the user has approved the authentication on his mobile.
Exactly. Blocking is the only way to implement this in v3. Alan DeKok.