reference leak - disconnect user event

[gabpasro]

Hello, I have detected that the reference to the user event 'disconnect' is not closed at any point.
I leave you a screenshot of the modification:

• Evidence:
  

• Path: <vi.lib>\LabVIEW Open Source Project\Connection\Connection\connection_process.vi
  

[francois-normandin]

Hi @Desistonboard ,
thanks for the report. You are correct that there is a memory leak!

However, the fix will need to be introduced in the onDisconnection callback method to be a symmetrical action to the event's creation in the CreateReferences callback. The connection process, being asynchronously spawned, could have its caller fail to launch it or abort its thread with no possibility for the process to complete its full execution. In those (admittedly rare) occasions, we would still generate a memory leak.

[gabpasro]

Yes you are absolutely right.

In this context, since the toolkit does not handle reconnection it would not make more sense:

1. Test if the connection is established correctly.
2. If not, do not create the notifiers or raise the dynamic vi, and obviously in closing, if necessary, do not try to close the references.

Example:
Path: <vi.lib>\LabVIEW Open Source Project\Connection\Connection\Connect.vi

Thank you for your open source contribution.

[francois-normandin]

This would not work. You see, node 1 cannot error out and the process has to be launched even if there is an issue with 2, so that the developer can call connect explicitly after running this node.

It's not obvious by looking at the block diagram, but the workflow is in parallel like this:

Maybe it helps if I re-organize the diagram like that:

If you think a reconnection node is useful to have, I can analyze the use case. However, Connect has a process because some connections require a Handshake to complete the connection transaction. I chose to enable this through a Handshake override that is handled by the process asynchronously. In the case of basic TCP, you do not need it. Look at the Queue example or the TCP-TLS extension package to see why this is the case.