jsmorley wrote:So as far as I can tell Aragas, it seems to work fine.
I have committed the changes to https://github.com/jsmorley/CheckNet, and will update the CheckNet .rmskin in a few minutes so others can try it out.
Thanks once again for your help with this. I think it is pretty clear how it works, and although this code is pretty specific to my functionality, (with only one thread ever being active at a time for instance) it has gone a long way toward helping my understanding.
I owe you a vodka!
Happy to help!
I'll make some optimizations in my fork. So don't forget to check it out later
I have added a "FinishAction" option to the plugin measure, which will do the same thing it does on other "threaded" plugins like WebParser and FileView. It will execute any defined Rainmeter actions when the plugin has "finished" doing all the connectivity tests in the thread.
This is a better way to handle having the measure take some action when the plugin completes, as with threading you can't really depend on OnChangeAction or OnUpdateAction to be a reliable indication that the measure has completed its work.
To be honest, I think we have a bigger more fundamental problem with the entire plugin and how it is threaded.
Much like WebParser does, this plugin can easily be "hung". In fact, it will hang itself sooner or later if you just leave a skin using it running and checking the network every 5 seconds and the internet every 20 seconds.
I think it is related to the "abort" function we are using to end a running thread when the skin is refreshed (or in the case of this plugin, when the processing done in the thread is completed. I really don't think "abort" should ever be used in the context of Rainmeter, as terminating a thread in an ungraceful way just causes problems.
Rainmeter is fine, and the skin keeps running with no error, but the plugin .dll gets "hung" and just ignores any calls to it from the skin. The only solution is to completely exit Rainmeter, so Windows "cleans up" any orphaned .dll's, and restart Rainmeter. Then it works fine, for a while...
I will have to do some investigating and talking with poiru about a better way to manage these threads. It has been a long-standing problem in WebParser, and I don't want to add another one to the list.
jsmorley wrote:
I think it is related to the "abort" function we are using to end a running thread when the skin is refreshed (or in the case of this plugin, when the processing done in the thread is completed. I really don't think "abort" should ever be used in the context of Rainmeter, as terminating a thread in an ungraceful way just causes problems.
jsmorley wrote:
I opened up Process Explorer and watched the threads that Rainmeter was creating and maintaining while the skin was running, unloaded and refreshed, and it seems to work as expected. A new thread is created for a hot heartbeat while it checks the network and / or internet, and then goes away.
It's more than likely that I'm misunderstanding how Process Explorer works, but I can't replicate the behavior you describe. For me, a new thread is spawned every ~5 seconds, with a another thread spawned in addition ~20 seconds. None are deleted immediately; instead after a few minutes they are all cleaned up at once (garbage collection?)
