Jump to content

PostgreSQL Library


Recommended Posts

  • 1 month later...

I've just pushed new branch to Dr Powell's repo, and built a new version of this package.

I used LabVIEW 2017 SP1.

What's new :

  • added support for Linux Rt targets (possibly Linux in general but not tested) (issue #1)
  • added support for boolean parameter (issue #2)
  • fix a weakness in parameter detection (issue #3)

VIP 0.2.2-b16 can be downloaded from here.

  • Like 1
Link to post
Share on other sites
On 1/21/2021 at 1:44 PM, ShaunR said:

It depends how it is compiled.

There seems to be a function to determine whether the binary is thread safe, yielding 1 if it is and zero if it isn't.



int PQisthreadsafe();

Source

Running on Linux RT with the libpq.so compiled by NI : so they did build the library as thread safe

and I get the same on Windows with the libpq dll deployed with the VIP.

image.png.a28d33a9535794cbc9ccd2042b58d6c0.png

Edited by Antoine Chalons
Link to post
Share on other sites

I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine.

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

Link to post
Share on other sites
2 hours ago, Antoine Chalons said:

I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine.

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context.

What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply crashes even if you observe proper data flow dependency so that functions never can attempt to access the same information at the same time, would be utterly strange. That would not be just the reentrant setting causing multithreading unsafe issues but something much more serious and basic.

I at least assume that you tried this also in single stepping highlighting mode? Does it still crash then?

Edited by Rolf Kalbermatter
Link to post
Share on other sites
3 hours ago, Antoine Chalons said:

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

That's because it's hard-coded to return a simple Boolean when compiled.

int
PQisthreadsafe(void)
{
#ifdef ENABLE_THREAD_SAFETY
    return true;
#else
    return false;
#endif
}

 

  • Confused 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.