CLNs and threading

[asbo]

I'm having a go at implementing some of the Windows Sockets API and run into the same issue Rolf talks about in this post:

Quote

Just one more comment. The error handling with WSAGetLastError() is probably never gonna return a meaningful error. (WSA)GetLastError() retrieves a thread local storage value set previously by another function. That assumes that the previous function and GetLastError() are called in the same thread and without any other function in between that could set that value. Since the CLN's are set to execute in any thread this is absolutely impossible to guarantee and in my experience actually almost never happens either.

Not even setting both CLNs to execute in the UI execution system would be able to guarantee proper operation, since theoretically there could still execute another call to an API that influences this value, between when LabVIEW calls the recv() function and when it eventually calls the WSAGetLastError().

My issue is a little more fine-grained, perhaps. If I have my two CLNs SomeWSACall() and WSAGetLastError() on the same block diagram, happy days - I get my socket error code. However, I wrapped that WSAGetLastError() call into a subVI and now it doesn't work! Evidently, using a subVI ensures that something, somewhere makes a call to WSASetLastError() in the UI thread. I did open a support issue with NI about it, but I expect they'll tell me what I already know.

Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

Though I'm referring to specific functions, this is really more broad - I will probably be working with several other Windows APIs in the future and it would be helpful to have a complete grasp of the nuances here.

[ShaunR]

Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.

Edited September 18, 2011 by ShaunR

[asbo]

The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.

That solidifies one part of it ... I expect that if I'd opened up the help file, it would have been right there waiting for me. Thanks nonetheless.

Does anyone have any feedback on the balance of my questions?

[GregR]

LabVIEW doesn't know how long any specific CLN will take to execute, so we assume that they will all take long enough to be worth scheduling in parallel with other code (clumping separately). This increases the chance of multiple CLNs not running in the same thread. However, there is a solution. Subroutine VIs come to the rescue. Subroutines always generate a single clump and will execute all their code in a single thread. So as long as your socket call and the getlasterror are made under the same subroutine, they will execute in the same thread. This even covers the case where the getlasterror is encapsulated in other subroutine VI for reuse.

There is one extreme corner case where other code could be run between the 2 calls. It involves the subroutine starting cooperatively in a thread under a call to a LV built DLL. The vast majority of applications don't even create this situation and it is pretty unlikely to happen even in those that do.

[asbo]

Greg, thanks for your reply. Using subroutine priority is somewhat inconvenient for development, but so far it appears to be doing the job. I don't think that corner case will ever apply to this code, so it looks like I'm in the clear. Thanks!