freeing ports

[grammoboy2]

NSM (non-session-manager) manages jack clients using OSC (liblo) and all those jack applications with NSM support mostly use liblo as well. NSM kills jack applications with SIGTERM when it closes a session. Sometimes this process can get stuck, it can take really long before all clients died (like a traffic jam). It might have something to do with those jack applications trying to free the udp osc port.

In the source code of nsmd I read the following:

"/* sleep a little bit because liblo derives its sequence
* of port numbers from the system time (second
* resolution) and if too many clients start at once they
* won't be able to find a free port. */"

https://github.com/linuxaudio/non/blob/master/session-manager/src/nsmd.C#L1311

Probably something similar is happening when freeing the ports.

Reporting this might help to improve liblo. It's not that I desperately need a fix at the moment.

[radarsat1]

Thanks, always good to know about how liblo is used. However, in this case the application is starting the liblo server with NULL as the argument to lo_server_new, which makes liblo use this heuristic port allocation scheme. Of course it will not always serve every application, so in that case it is easy to override it by providing a port number there. So they could be allocated by some independent mechanism and perhaps closed some other way. It is also up to the caller to call lo_server_free as appropriate. Perhaps this could be done in a signal handler. Unfortunately I have no idea if this could cause an application to stall.

[grammoboy2]

I have no idea if this could cause an application to stall.

A other thing that comes to mind is the use of threads and something that blocks there (lo_server_thread), mutexes? But to me the problem has similar characteristics as the "if too many clients start at once"-problem.
Strangely enough I couldn't detect this problem with RaySession, which is also NSM manager, which uses python liblo and python qt library to kill the jack clients IIRC. Maybe there is some delay build in to stop the jack clients there (accidentally or not)... I don't know.