I am running a single threaded C++ program which publishes tables A and B.
I am using the k function below to publish the updates asynchronously.
k(-handle, (S)".u.upd", ks((S)table_name), data, (K)0)
I am not explicitly calling r0(data) on the data because calling the k function decrements the reference count.
I have confirmed this to be the case by running m4(0) before and after the call to k.
My question is, do I need to change anything in terms of memory management if I want to move the publishing of tables A and B into separate threads? Is it ok to call k from within a thread? Can both threads call k at the same time for instance? Just want to be aware of the dangers if any
Ok thanks, so to clarify, we are not calling k from a q process, via a shared library. We are running a C++ process where different threads are responsible for publishing data to different q processes using the k function. The threads are created using std::thread. Before the threads are created, the handles to the different q processes are opened and then subsequently passed to the threads to use during the async publish.
This has been working well for us so far, in that data is being received by the q processes, and we can see that m4 (which returns the memory for the current thread) is showing no memory leaks. Are you saying there could be a danger with this setup?
We have been looking at the API reference doc, but it doesn't mention this restriction in regards to k, see https://code.kx.com/q/interfaces/capiref/#k-evaluate. Please let us know if there is another reference we should be using.
I was just looking through old discussions, and can came across this one
Tel: +44 (0)28 3025 2242
Tel: +1 (212) 447 6700
Tel: +61 (0)2 9236 5700