Advanced "Create Network Stream Endpoint" should be interruptible

[igagne]

I think there should be a way to have a network stream endpoint creator continuously wait for a connection. The problem with that is there's no good way to stop that "wait forever". I propose we create the network stream in two parts. The first one just creates a handle that can be closed later. The second one does the actual waiting like the normal create endpoint.

[AristosQueue (NI)]

[AristosQueue (NI)]

I don't think that changing the Create node is possible. I think it has to poll like this because LV calls into low level network routines supplied by the OS. We give them a time out and that's how long we are going to wait. If you want an interruptible wait, you have to do polling, as I show in the picture above.

I don't own this API, so I'm not absolutely sure, but given what I could find about the deeper layers, I think this is the only option open to upper level APIs. In theory, I suppose LV could write a wrapper layer that does this kind of polling ourselves using a separate refnum -- the unconnected refnum and the connected refnum as two separate entities -- but then we'd need to put both versions into the palette and explain what was going on and it would complicate the API considerably, IMHO.

Off the top of my head, I'm not seeing anything better.

[igagne]

Thank you for the example. I think it gives us something concrete we can talk about.

Will that code cause a memory leak because you aren't calling Destroy Stream after every timeout?

With the TCP pallet, you can close the listener reference to kill wait on listener. I was hoping that's the sort of behavior we could have here. A background poller is not ideal but at least it would have polymorphism.

Here's the "new stuff" count in my head. It's likely I'm not accounting for everything:

New primitive for "create handle"

Existing create function can take in string or handle

Destroy can take in handle or endpoint (existing functionality)

[AristosQueue (NI)]

> Will that code cause a memory leak because you aren't calling Destroy Stream after every timeout?

No. There's no stream to destroy. Nothing got created if the function timed out.

> Here's the "new stuff" count in my head.

As in, this is the list of stuff you'd like to see NI write to add to the existing API for network streams? Or this is the list of new stuff that my picture makes you think about going forward?

[AbandoningCausality]

FYI, I just ran into an application where the 100 ms timeout as shown above continued to throw a timeout error even though the other "Create Endpoint" was siting there trying to connect. I got it to work with a 500 ms timeout which makes the "cancel" button less responsive and makes me wonder if there are situations where that might not be long enough. Using the TCP model where you create a listener and then can kill any listeners out there would be better.