LabVIEW Project Providers

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

When launching LabVIEW, the splash screen freezes forever on "Initializing plug-ins" if a Project Provider Interface VI statically references members of some LVLibs or LVClasses.

Some libraries are for some reason OK to statically reference; others are not. I can't fully characterize what's causing the freeze. In many instances, this has forced a refactor, bringing methods outside of a library in order to call from a Project Provider. Other times, the answer lies with creating proxy VIs that dynamically launch class members that cannot effectively be pulled from the class.

You can probably recreate this issue yourself (YMMV) by taking a known-good Project Provider, then just adding its interface VIs to a LVLib and naming it something like MyProjectProvider.lvlib

I have toyed with access scopes (making all members public, in hopes of avoiding known limitations) and demoting classes to LVLibs in order to avoid loading all class members; neither of these ideas worked.

Right now, the solution is to ensure that static dependencies are just not library members; but can someone give advice on best practices, and how to still use libraries that will not freeze the initialization of the Project Provider?

0 Kudos
Message 1 of 10
(512 Views)
9 REPLIES

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

That's interesting.  I am using libraries in my current project provider without any difficulty.  We should compare notes.

0 Kudos
Message 2 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

Jack,

are you saying you use Static Vi references in one or more of the interface VIs, instead of using file constants to point to the provider handling files?

Or, do you mean that you see this if you use static links to a class member in any provider VI?

/J

0 Kudos
Message 3 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

niACS wrote:

That's interesting.  I am using libraries in my current project provider without any difficulty.  We should compare notes.

Agreed!

And to be clear; *most* libraries, not all, cause deadlock. It's hard to characterize what's different between those that do, and those that don't.

To give an example, see the virtual folder below that defines an API -- these members were originally designed as an LVLIB -- yet calling any item from a Project Provider Interface VI results in deadlock on initialization.

Screen Shot 2013-01-16 at 2.52.17 PM.png

And the level of complexity in these guys is nothing special; also, they have specifically been crafted with no dependencies on other libraries (for the same reasons as above). Perhaps this API would be a good one to focus on, if we want to find the culprit (right now the exercise is academic, but could be helpful in the future or to feed forward into future Project Provider improvements)

The resolution for this problem has always been to a) demote the API from being contained by a library into just a folder of VIs (like above), or b) creating a proxy that dynamically launches the dependency, effectively eliminating the static linkage.

0 Kudos
Message 4 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

Mellroth wrote:

Jack,

are you saying you use Static Vi references in one or more of the interface VIs, instead of using file constants to point to the provider handling files?

Or, do you mean that you see this if you use static links to a class member in any provider VI?

/J

I think these static dependencies were all just simply from a regular subVI call of a .lvlib/.lvclass method -- not necessarily referring to a static VI reference. But both cases (static calls and static VI refs) would cause the deadlock -- basically, if for any reason the deadlocking class shows up in the VI hierarchy of the Project Provider Interface VI, it'll deadlock during init.

0 Kudos
Message 5 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

niACS wrote:

By the way -- I didn't put two-and-two together who 'niACS' was until this thread -- always peripherially just assumed 'niACS' was a generic name for some NI Branch office

0 Kudos
Message 6 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

Jack,


Sorry I didn't see that this wasn't resolved until just now.  I tried doing a basic test with a primary and secondary example in LabVIEW 2012, and as niACS claimed I can also not reproduce it.  Is there any small, shareable example that you can provide that reproduces this so we can try some debugging on our end?

0 Kudos
Message 7 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

David_L wrote:

Jack,


Sorry I didn't see that this wasn't resolved until just now.  I tried doing a basic test with a primary and secondary example in LabVIEW 2012, and as niACS claimed I can also not reproduce it.  Is there any small, shareable example that you can provide that reproduces this so we can try some debugging on our end?

I will keep an eye out for a small, reproducible example. The problem is that I have not characterized the minimum set of circumstances that causes this.... nevertheless, will keep an eye out.

0 Kudos
Message 8 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

Sounds good, let me know and I'll do some digging.

0 Kudos
Message 9 of 10
(450 Views)

Re: Most LVLibs and LVClasses as static dependencies tend to deadlock initialization of Provider

Closing the loop, I'm now nearly certain the culprit of this problem.

Libraries, when loaded as part of the initialization sequence (Provider Startup, Global Init, and other callbacks that happen during the "Initializing plug-ins" step on the splash screen) will deadlock the Splash Screen if the library has declared a SortType property. In other words, removing the following line from the library (LVLIB or LVClass) definition will solve this problem:

<Property Name="NI.SortType" Type="Int">1</Property>

If you're running into this type of deadlock, check for this property in all classes statically or dynamically loaded during initialization, and remove that line from the library definition.

Message 10 of 10
(450 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.