Start Asynch Call plus Active X is causing event structure in parallel thread to NOT timeout

[GregFreeman]

First off let me say, I understand sending any sort of heartbeat in a timeout case is not a good practice. What I am looking for here is why this is happening.

 

I am launching a VI in its own loop using the "start asynchronous call" VI. The launched process then loads a large HTML file into an ActiveX web browser. When this loading happens, the event structure of the loop that originally did the launching doesn't timeout and no heartbeat message is sent. Can anyone speak to the reasoning of this? Is the event structure somehow being blocked by the ActiveX doing stuff in the UI thread. At first I thought my whole application was hanging, but then I pulled the heartbeat out into its own loop that sends it every 100 ms and the problem went away. It is obviously related to the event structure itself. The included VIs and HTML file reproduce the problem.

 

Thoughts?

 

timedelay.zip

Edited June 28, 2013 by for(imstuck)

[QueueYueue]

... Is the event structure somehow being blocked by the ActiveX doing stuff in the UI thread....

I'm not super good with the specifics of your problem, but this is whats causing your issues.

 

I've seen similar problems where you're trying to use an activeX component to talk to galil motion controllers, but a lengthy UI task delays your activex calls.

[Rolf Kalbermatter]

I'm not super good with the specifics of your problem, but this is whats causing your issues.

 

I've seen similar problems where you're trying to use an activeX component to talk to galil motion controllers, but a lengthy UI task delays your activex calls.

 

And that is not necessarily LabVIEWs fault. Most ActiveX controls/servers are not designed to be multithreading safe, declaring themselves to be apartment threaded, meaning any specific caller has to call them always from the same thread. LabVIEW being itself highly dynamic threading can only guarantee this by executing them from the only special thread it knows about, and that is the UI thread.

 

Theoretically LabVIEW could of course extend its already very complex threading model by providing a dynamic number of fixed threads (nice contradiction in here ) one for each apartment threaded ActiveX control the user wants to run, but that would make the whole threading in LabVIEW mainly even more complex and more likely to fail under heavy conditions, so it would buy little in the end.

 

The best solution would be to require the ActiveX component developer to provide a free threading compatible component and register it as such in Windows. Then LabVIEW can call it from any of its threads and does not have to push it into the UI thread. But as already pointed out, free threading capable ActiveX components are a very rare species, since they are not exactly trivial to develop and the apartement threading works in the majority of use cases good enough.

[GregFreeman]

The best solution would be to require the ActiveX component developer to provide a free threading compatible component and register it as such in Windows. 

 

Unfortunately, I can't contact Microsoft to have them change their IE Active X component  , so I'll just have to live with it.

[QueueYueue]

Unfortunately, I can't contact Microsoft to have them change their IE Active X component  , so I'll just have to live with it.

I think this is pretty much always the case.

 

Roflk, do .NET components behave the same way with respect to threading? I've recently had some success with tlbimp and i'm curious if that would change anything. I think for(imstuck) would have to use aximp since he's working with a control instead of just a component, but I'm not to sure about that.

 

Tlbimp and aximp create a .net wrapper around an activex component.

[Rolf Kalbermatter]

I think this is pretty much always the case.

 

Roflk, do .NET components behave the same way with respect to threading? I've recently had some success with tlbimp and i'm curious if that would change anything. I think for(imstuck) would have to use aximp since he's working with a control instead of just a component, but I'm not to sure about that.

 

Tlbimp and aximp create a .net wrapper around an activex component.

 

Well I"m not sure about multithreading issues with respect to .Net but .Net is more flexible for sure than ActiveX, which was build on OLE with all its pre-Win32 legacy issues.

 

So it does seem reasonable that the .Net component is by default instantiated and run as a separate thread and therefore satisfies the Apartment threading requirements of the ActiveX component, without being locked into the LabVIEW UI thread. How much the .Net component would have to do, to actually make sure it is working like that, I would not know. It is entirely possible that the .Net component has to manage the entire threading explicitly for the ActiveX component.Since the ActiveX component doesn't really count as fully managed service in terms of .Net there will also have to be some explicit managed-unmanaged translation code in the .Net component. Fortunately if you use tlbimp/aximp to create the ActiveX wrapper you should be safe from having to bother about these issues.