Wait at Rendezvous bugs

[Daklu]

---

Dan DeFriese wrote:

If the program needs an element to be enqueued (e.g. in an SEQ implementation) then it should be the responsiblity of the programmer to handle it appropriately.

---

I agree with you.  AFAIK the only NI vis that ignore error in are those that close references (and one could argue that even those shouldn't ignore errors.)  Changing that behavior means I have to start opening help files to find out how each vi handles errors.  Not only that, but that would change the default behavior of the api (a big no-no) and break* many existing applications.

*By "break" I don't mean a broken run arrow--I mean change the behavior of the app so it no longer responds the way it was designed to.

[tbob]

Dan and Daklu:  Good points.  I didn't think of breaking existing code.  I agree it should be up to the programmer to handle the errors.  It depends on the structure of your code.  In my particular application (state machine) an error should cause a call to the exit state.  In this case I call enqueue without an error in so that I can queue up the exit state.  The actual error gets routed to error out.  Those who use state machines should be aware of the possibility that your exit state will not get enqueued if there is an error and your enqueue is wired with error in.  This is just like what happens in the Rendevous bug.

As for closing functions, they should close regardless of error in.  If it didn't, we would have to add extra code to check for errors so that we can actually close.  I would not want to do this everywhere I have a close function.  Closing is a valid function in shutting down gracefully, regardless of error.

[Daklu]

---

tbob wrote:

As for closing functions, they should close regardless of error in.  If it didn't, we would have to add extra code to check for errors so that we can actually close.

---

The main benefit of having an internal error check is that the api is consistent.  Having an intuitive and consistent api goes a long ways towards making happy developers.  Are all NI's vis except for Close reference functions wrapped in error handling checks?  I think so, but I don't know for sure.  I still find myself frequently pulling up documentation to find out how a vi handles errors--just to make sure.  If Close did do an internal error check and you wanted to close regardless of error state, just don't wire the error in terminal.  No extra error checks needed.

Note I'm not actually arguing that the close prims should do an error check; I'm just pointing out that a valid argument could be made.  I suspect NI decided to skip error handling in close prims because that satisfies 90% of the use cases and it makes it easier for new programmers to avoid memory leaks.  In those respects I think they made the right choice.

[tbob]

Daklu:  Another valid point about uniformity.  But what is done is done.  I'm happy with the close functions as they are, but your statement about uniformity makes a lot of sense.  Now you have me wondering, what other functions do not test error in???  Maybe an NI guru could enlighten us.

[kodykoala]

Ok, I tried all of the suggestions above and I cannot get my rendezvous to work.  Let me give some background.

I have just upgraded from 8.5 to 2009.  I noticed that the rendezvous functions are completely different.  I stepped through and

probed my Vi and I am always crashing at "Enqueue Element" in "Release Waiting Proc.vi" inside the "Wait at Rendezvous.vi".  Not sure what to

do next. Are there things I should be looking for?  Thanks for any help.

[Albert.Geven]

Regarding close functions. It was somewhere defined that close should always close but propagate an existing error.

So not fiddling away any error.

[Ray.R]

---

@Daklu wrote:

---

tbob wrote:

As for closing functions, they should close regardless of error in.  If it didn't, we would have to add extra code to check for errors so that we can actually close.

---

The main benefit of having an internal error check is that the api is consistent.  Having an intuitive and consistent api goes a long ways towards making happy developers.  Are all NI's vis except for Close reference functions wrapped in error handling checks?  I think so, but I don't know for sure.  I still find myself frequently pulling up documentation to find out how a vi handles errors--just to make sure.  If Close did do an internal error check and you wanted to close regardless of error state, just don't wire the error in terminal.  No extra error checks needed.

Note I'm not actually arguing that the close prims should do an error check; I'm just pointing out that a valid argument could be made.  I suspect NI decided to skip error handling in close prims because that satisfies 90% of the use cases and it makes it easier for new programmers to avoid memory leaks.  In those respects I think they made the right choice.

---

Very good point.

I just realized something.  The last time I checked how the Close function handles errors was a few versions ago.  So it may be wise to revisit them once in a while.

As Albert mentionned, and from what I recall, the Close function closes references irregardless of errors that may have occurred before calling it.

We also have to be careful when creating templates of API's that error handling is properly designed and documented; otherwise, there will be unhappy programmers.

[TrevorChristman]

Jim,

  Thank you for your extremely detailed and thoroughly researched bug report.  Your work made this error much easier to reproduce and correct - would that all the CARs that come across my desk looked like this one. 

  In addition, the subtle flaws you pointed out only express themselves in a unique, advanced use case.  I bet we'd have never encountered it internally, so without your research and report it probably would have never been fixed.

---

Jim Kring wrote:

The only think that I can think of is that the reference became invalid because the top-level VI that created the reference went idle.  But, that doesn't make sense, because "Wait at Rendezvous.vi" is the same VI that created the queue and it's still running!

Or, is there a possible way the top-level VI could have gone idle, even though this VI is still running...

This application uses a lot of top-level VIs, reentrancy, and dynamic dispatch.  Here's a possible scenario.  This particular reentrant instance of "Wait at Rendezvous.vi" is inside a reentrant dynamic dispatch VI. So, it's possible that the dynamic method (and therefore this particular reentrant instance) could be called from any one of several top-level VIs.  So, the recycled queue reference (in the shift register) starts out as valid, and then becomes invalid when the top-level VI (that actually made the dynamic call that created the recycled queue reference) goes idle -- BOOM, invalid queue reference.

---

  You were exactly correct about what causes the queue reference to go invalid.  I've attached a contrived use case which demonstrates the behavior:  Open Client 1.vi, Client 2.vi and Client 3.vi and use execution stepping to execute the sequence structures in the order specified in the block diagram comments.

  Thanks again for your awesome contribution.  As an additional thanks, I've made arrangements for NI to send you a LabVIEW T-Shirt.  If you like, I'll sign one of the sleeves or something.  : )

  --Trevor Christman

     LabVIEW R&D

[Jim_Kring]

Hey Trevor,

Thank you for the kind words, the t-shirt, and (especially) for correcting the problem.  I look forward to more bug-free fun with rendezvous in a future version of LabVIEW 🙂

Cheers,

-Jim

P.S. Ya, it's definitely a corner case, but that's where life's the most interesting 🙂