Re: Possible problem with C++ based CREATE FUNCTION

Hai Dave, I’ll leave the solution to your missing lib. to someone else, but after having read your email, I’d like to point out two things: i) we do not recommend external “interference” in the transaction management. We’ve seen various disasters caused by such interference in the past. Sometimes, they surface after having been run for months in production systems. What you’re doing here has high potential for deadlocks, because you’re adding more locks next to the MonetDB internal locks. It’s more advisable to first try to resolve the concurrency issues you described here in your application set-up. ii) the SQL C/C++ UDFs are more suitable for prototyping. A more stable alternative to add UDFs is described in this repository: https://dev.monetdb.org/hg/MonetDB-extend Regards, Jennie

On 3 Sep 2019, at 03:16, Gotwisner, Dave wrote:

I am trying to create a function that works around concurrency issues that are documented, and that we are seeing, when doing simultaneous “create table” statements and bulk insert statements (or selects) off of other tables.

To do this, I am implementing a function that uses a boost::shared_mutex that we call around transactions.

We are using a custom version of the boost library, so it is installed in a non-standard place: /usr/local/boost-1.54.0 for development, and /opt/xxx/ for production.

From the documentation, it appears that I can use #pragma LDFLAGS and CFLAGS to point to the non-standard directories. It appears to honor the CFLAGS option, but not the LDFLAGS option. If I use the standard /usr/lib64 libraries, calling my function works (but with the wrong library). Adding the #pragma in, I get the following link error:

Failed to open shared library: libboost_thread.so.1.54.0: cannot open shared object file: No such file or directory.

If I modify LD_LIBRARY_PATH before starting MonetDB, the problem goes away. Ideally, we don’t want to have to add all of our relevant directories into the environment, but would expect the #pragma to work.

Here is the function definition: CREATE FUNCTION rwlocker(input INT) RETURNS INT LANGUAGE CPP { #pragma LDFLAGS -L/usr/local/boost-1.54.0/lib -lboost_thread #pragma CFLAGS -I/opt/tc3/include -I/usr/local/boost-1.54.0/include

#include

// use lock() for schema changes, lock_shared() for inserts and queries static boost::shared_mutex readerWriterMutex;

result->initialize(result, 1); int val = input.data[0]; switch(val) { case 1: // shared lock readerWriterMutex.lock_shared(); break; case 2: // shared unlock readerWriterMutex.unlock_shared(); break; case 3: // unique lock readerWriterMutex.lock(); break; case 4: // unique unlock readerWriterMutex.unlock(); break; default: // Error break; }

result->data[0] = val; };

Invocation is easiest with: select rwlocker(12); which will just output a 12, bypassing the reader/writer locking.

Any thoughts on why #pragma LDFLAGS doesn’t appear to work right?

We are using 11.33.3 on CentOS 7.3.1611

Thanks,

Dave _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list