how to disconnect from the hs4.exe gracefully

[mnsandler]

alex0603 , dcorsus guys i need professional help with this one.


After my plugin shuts down, and the command window goes away, there is still a connection to HS4. see process explorer results below.

In my shutdownio, i set all my primary object to Nothing

My main.vb has the following as the last statement

_plugin = Nothing

I need to figure how to break this connection

Any ideas?

[Michael McSharry]

In HS4 the shutdown method is OnShutdown.

What I do in this call from HS4 is call each of my classes shutdown method. Set all my timers to nothing after stopping them. Close all my files, ports and sockets. Release all my queue and thread semaphores. Clear all Dictionaries that are holding objects. In the past I aborted any thread that I opened, but now I use thread pool so no longer necessary. I make no effort to set the plugin to nothing.

I have not looked at Process Explorer, but Task Manager does not reflect my plugin process after shutdown.

I have plugin and HS stop/start/restart capability supported in mcsMQTT and I have no issue with being blocked because of a resource being taken.

My main is

sub Main(args As String())
plugin.Connect(args)
Console.WriteLine("Exiting Main")
End Sub

[dcorsus]

Same here, in OnShutDown, the PI stops all timers, speakerclients, close ports, return weblinks, dispose objects etc.

[mnsandler]

my plugin is not getting a call to OnShutdown when i disable the plugin from the Plugin/Manage page. Instead the old ShutdownIO is called

edit: change to

Protected Overrides Sub onShutdown()

and now its being called

[dcorsus]

my plugin is not getting a call to OnShutdown when i disable the plugin from the Plugin/Manage page. Instead the old ShutdownIO is called

edit: change to

Protected Overrides Sub onShutdown()

and now its being called

[mnsandler]

for the record, i think the change that finally worked was setting my Threads to nothing after they stopped. I have logic to exit the thread when the plugin shuts down but i guess that wasn't good enough

[Michael McSharry]

I found that using "ThreadPool.QueueWorkItem" to be more efficient than "New Thread" and does not require any additional management to assure resources are not tied up. For example, the oResendThread created with the first method requires the plugin to manage the resource. This object is not created in the second method. Any cleanup activity that may be needed is handled implicitly by .NET. as it manages the ThreadPool.

From

oResendThread = New System.Threading.Thread(AddressOf ResendThread)
oResendThread.Start()


To

System.Threading.ThreadPool.QueueUserWorkItem(AddressOf ResendThread)

[mnsandler]

thanks Michael

I started using the threadpool for newer code, just never went back and converted the original ones

[alexbk66]

I'm using Task.Factory.StartNew