Open JPfeP opened 5 years ago
Indeed, creating an OSCThreadServer
instance starts a thread that never ends, and that will listen to all sockets the server has created through calls to listen()
. The solution there would be to only create one server, and in the case the address can't be bind to (i assume that's the error you catch in your except?), instead of recreating an osc_server, just call listen again on it, with the correct parameters. calling stop() shouldn't be necessary in this case, as the socket is only created and added to the list of sockets to listen to if the bind is successful.
edit: maybe adding a __del__
method to OSCThreadServer that would stop the thread could be useful though.
Just a trivial note that __del__
alone would not be a good solution, because it relies on the garbage collector getting around to it.
Hi,
This issue might be related or not to issue #43.
In my new Blender add-on project, I implemented an automatic retry function for the OSC server that fires every 500ms. It's quite handy for the user.
Lately I observed Blender taking all of my CPUs and, after investigation, it happens when the server is not able to connect (due to wrong settings) for a long time and therefore is still trying to connect again and again. I can reproduce the problem, the CPU usage rises very slowly and steadily until the app becomes unresponsive. It doesn't happen when the add-on connects successfully at the beginning and keeps the connection running, that's why I only discover the problem now.
If after all the failed attempts the server can at least connects it doesn't solve the issue, the CPU usage stays high and the only solution is to close Blender.
Here is an extract of my code:
As you see I tried to clean the reference "osc_server", setting it to "None", but it doesn't solve the issue.
This is with python 3.7.0 under Ubuntu 18.04 LTS and a fresh "oscpy" copy from github.