search

radarsat1 / liblo

liblo is an implementation of the Open Sound Control protocol for POSIX systems
GNU Lesser General Public License v2.1
192 stars 60 forks source link

freeing ports #158

Open grammoboy2 opened 7 months ago

grammoboy2 commented 7 months ago

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

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 commented 7 months ago

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 commented 7 months ago

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.