'Select File Path' popup will block 'Open file' vi

[Andrey_Dmitriev]

Hi,

Sorry, I guess the answer was already... You don't need to play with DLLs etc.

Just place Open/Close file functions out of loop:

Andrey.

Message Edited by Andrey Dmitriev on 11-21-2008 08:30 AM

[Norbert_B]

Really nice work, Andrey!

This behaviour is obviously in fact created by a blocking call to the UI thread made by the popup. I searched a little in google (it is your friend!) and found in a .NET forum the following statement:

"Worse, if another thread calls .Invoke on a UI object owned by the blocked thread, the thread too will be blocked." 

So it seems that Open/Create/Replace File.vi executes a call to the UI thread even if a filename is connected to its input. I don't know if this is intended, but it definetly blocks if another thread already made a similar call to the UI thread.

 Andrey's solution is the recommended way to work with files if each iteration has to work with the same file. So please stick to this.

hope this helps as a first solution,

Norbert 

[Andrey_Dmitriev]

Thanks, Norbert.

Yes, here some interference with UI thread. The only interesting point is following: Open File blocked by File Dialog only. This function not blocked by calling OneButtonDialog, even not blocked by calling DLL in UI thread (which normally block all threads in UI mode). This fact can position this as "bug" and should be investigated by NI R&D.

Andrey.

[Norbert_B]

Andrey,

i think that the problem occurs because the file dialog is the windows file dialog which is called by the path browse button as well as the create file.vi. So i asume that there is no block of the UI thread itself, but with the file dialog from windows. I think it is possible that the lock due to the dialog does not occur if the calls to this dialog are located in different process (OS processes), but i am not sure.

Norbert 

[Wiebe@CARYA]

"Andrey Dmitriev" <x@no.email> wrote in message
news:1227204611222-812387@exchange.ni.com...
> Thanks. The best way to&nbsp;prevent such &quot;deadlocks&quot; is avoid
to use property nodes, DLLs in UI thread, etc (in general all elemenths
which caused switch execution thread to UI) in any time-critical
loops.&nbsp;For example - there are two loops - they almost the same, but
one is faster, and another is slow:&nbsp;<img

The original poster's problem doesn't have property nodes, DLL's in UI
thread, and still hangs other loops.

My suggestion was to use reentrant dll's, and I don't see any other way to
create a file open dialog that does not hang other loops...

Regards,

Wiebe.

[Wiebe@CARYA]

Isn't it stange that a dialog hangs a function, just because the function
*might* call the same dialog? Seems to me that the only way to achieve this
is to explicitly program in this behaviour. If there is a path constant
wired to the file open, the dialog won't be called, and stalling the funcion
is redundant.

Regards,

Wiebe.

[TCPlomp]

I agree with Wiebe, it actually means that using 'Open File' is a no-no.

Ton

[F._Schubert]

One very annoying issue of this bug is, that the code pieces that block each other via the UI thread bottelneck do not need to share any dependencies (e.g. a front panel browse operation and a background logging process). That makes them very hard to debug (worse than those ugly race conditions). And the presented bug-inducers are not some exotic functionality, but very common to occure in parallel (dll call and File I/O and property nodes!).

I would really like to see that bug fixed, or at least have some tool to monitor the UI Thread bottleneck.

I now remember that on the case I struggled with that bug, I used a semaphore to pause the background polling process during file I/O. Not a nice workaroun, though.

Felix 

[alex.]

May I know how does experts make log into file normally, since I have many places in many vis need to be logged. Some vis are dynamically called out.

Thanks.

[Wiebe@CARYA]

I start my logging VI dynamically. If any VI wants to log something, it
sends a user event. The logging VI receives that user event, and logs the
message. Sounds complicated, and it can be done easier. But I use this
schema for all communication between processes, and with the right sub vi's
it is elegant, scaleable and result in reusable code.

Regards,

Wiebe.