LV silent crash with threading and oop on LV2009 f2

[Ben]

I logger SR# 1461927 and have asked for an AE to follow-up.

Ben

[User002]

Ben, thanks!

If you happen to get hold of an alpha vi.lib with the fix, I'd be interested in trying it out!

/Roger

[Ben]

---

RogerI wrote:

Ben, thanks!

If you happen to get hold of an alpha vi.lib with the fix, I'd be interested in trying it out!

/Roger

---

Don't hold your breath for that one. As I alluded to earlier I already went to the Ivory Tower over this crash once at it was deemed my fault (I agreed) but this one...

The main issue with being able to say yes this is crashing bug and will be fixed ASAP is the lack of a spec on this particular issue. To the best of my knowlege there is no official spec say how LV should respond when we attempt to queue up a class of the wrong type.

The good news is that Aristos Queue and his group take responciblity for "their baby" and act on them quickly, if appropriate.

Ben

[User002]

Ben,

What would be nice if NI at least could give the choice of going reference based in oop. The lack of this makes people create their own shoddy hack implementations. 😉 

Is the "Call by value"-paradigm another holy grail in the ivory tower? 

I am sure this has been up for discussion?  

/Roger

[Ben]

---

RogerI wrote:

Ben,

What would be nice if NI at least could give the choice of going reference based in oop. The lack of this makes people create their own shoddy hack implementations. 😉 

Is the "Call by value"-paradigm another holy grail in the ivory tower? 

I am sure this has been up for discussion?  

/Roger

---

Search on DVR (Data value reference ?) Aristos Queue gave us that with LV 2009.

Also see LAVA OOP for better answers that I can provide.

Ben

[User002]

Ben, the crash is still reproducible with your fix. What you need to do is to remove the bundle by name in the lockChild.vi method, then you will not see the crash.

I think the bundle by name is a perfectly sane LV code? 

Try it! 🙂

/Roger

[Ben]

---

RogerI wrote:

Ben, the crash is still reproducible with your fix. What you need to do is to remove the bundle by name in the lockChild.vi method, then you will not see the crash.

I think the bundle by name is a perfectly sane LV code? 

Try it! 🙂

/Roger

---

I'll let the NI AE "try it". I did get an update that they are on it, so keep this htread updated and watch for the official reply.

Ben

[User002]

Yeah, I noticed the Lava call by ref implementation. It has a few serious drawbacks. Correct me if I am mistaken?

- Its not possible to probe in a good way

- It needs a control queue for thread safety

- It is a hack

I am still waiting for the magic "New->RefClass", for example with the possibility to probe data and with thread safety mechanisms and setting vi's to be mutexes. Well, I can only wait.. LV 2010 maybe? 🙂

Regards, 

/Roger

[Ben]

---

RogerI wrote:

Yeah, I noticed the Lava call by ref implementation. It has a few serious drawbacks. Correct me if I am mistaken?

- Its not possible to probe in a good way

- It needs a control queue for thread safety

- It is a hack

I am still waiting for the magic "New->RefClass", for example with the possibility to probe data and with thread safety mechanisms and setting vi's to be mutexes. Well, I can only wait.. LV 2010 maybe? 🙂

Regards, 

/Roger

---

I have to admit, I am of a similar opinion. But then again I am not imune from developing my own hacks. My LVOOP apps (two delivered so far) edn up using what I read in Craig Larman's book as being called "active Object" (Objects that are created and stick around doing their own thing with any further method being invoked by other classes, DAQ Loop or Logging Loop are examples) that have methods like start logging, stop logging etc. In these design the invoking of the mehtod (start logging) is performed using a queue to request the method be performed and the results returned via anther queue. So most of the time they run in parallle but they "sync-up" when methods are invoked. So is that a hack? maybe. It did let me instanciate more than 100 objects all running in paralllel and played together very nicely.

Ben

[User002]

I vote for a full blown LV RefOOP toolbox starting with:

- mutex support

- threading support with a thread pool for easy access to each thread when probing

- interfaces support

 🙂

/Roger