# C API, calling k within a thread

**URL:** <https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529>\
**Category:** Community Support\
**Tags:** imported, kdb-and-q\
**Created:** [July 25, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529 "2023-07-25T00:00:00Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jerlucid](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@jerlucid](https://forum.kx.com/u/jerlucid)\
**Post date:** [July 25, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/1 "2023-07-25T00:00:00Z")

</div>

[https://learninghub.kx.com/forums/topic/c-api-calling-k-within-a-thread](https://learninghub.kx.com/forums/topic/c-api-calling-k-within-a-thread)

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)

&nbsp;

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

&nbsp;

Thanks

&nbsp;

---

<div class="post-metadata">

**Author:** ![oliviafray](https://avatars.discourse-cdn.com/v4/letter/o/8c91f0/32.png) [@oliviafray](https://forum.kx.com/u/oliviafray)\
**Post date:** [December 11, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/2 "2023-12-11T00:00:00Z")

</div>

In the context of business information APIs, it’s crucial to ensure that each q process operates independently with its own memory space. This independence in memory management necessitates careful consideration of data serialization and deserialization when transmitting information between processes. The distinct memory spaces for each q process alleviate concerns related to thread safety within a single process.

To guarantee smooth operations and prevent conflicts, especially in scenarios where multiple processes attempt to access or modify shared resources, a robust system design is essential. Consider implementing mechanisms to manage errors effectively, isolating failures in one q process to prevent any adverse impact on others. Additionally, for enhanced reliability, it may be prudent to explore the incorporation of a supervision system. This system can actively monitor the health of q processes and, if necessary, initiate restarts to maintain uninterrupted functionality.

In the realm of [business information API](https://www.globaldatabase.com/api"), these architectural considerations ensure the efficient and secure exchange of data between independent q processes, fostering a resilient and responsive system.

---

<div class="post-metadata">

**Author:** ![jerlucid](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@jerlucid](https://forum.kx.com/u/jerlucid)\
**Post date:** [December 11, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/3 "2023-12-11T00:00:00Z")

</div>

My question is about calling the k function, in the C API, from different threads within a non q process. A C or C++ process in this case. The q processes which are receiving the data are all independent and single threaded

---

<div class="post-metadata">

**Author:** ![gyorokpeter-kx](https://avatars.discourse-cdn.com/v4/letter/g/d07c76/32.png) [@gyorokpeter-kx](https://forum.kx.com/u/gyorokpeter-kx)\
**Post date:** [July 26, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/4 "2023-07-26T00:00:00Z")

</div>

How is the thread started? It is only safe to call k(…) from a thread started by q itself. So it’s OK to call from C functions called by .z.pg regardless of multithreaded input mode, but it should not be called from a std::thread.

---

<div class="post-metadata">

**Author:** ![jerlucid](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@jerlucid](https://forum.kx.com/u/jerlucid)\
**Post date:** [July 26, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/5 "2023-07-26T00:00:00Z")

</div>

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](https://code.kx.com/q/interfaces/capiref/#k-evaluate"). Please let us know if there is another reference we should be using.

&nbsp;

---

<div class="post-metadata">

**Author:** ![jerlucid](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@jerlucid](https://forum.kx.com/u/jerlucid)\
**Post date:** [July 31, 2023, 12:00am UTC](https://forum.kx.com/t/c-api-calling-k-within-a-thread/13529/6 "2023-07-31T00:00:00Z")

</div>

I was just looking through old discussions, and can came across this one

**[https://community.kx.com/t5/kdb-and-q/k-blocks-even-with-negative-handle/m-p/10468](https://community.kx.com/t5/kdb-and-q/k-blocks-even-with-negative-handle/m-p/10468")**

where Charlie was recommending calling k() within a thread because the call blocks until the send buffer receives the message, if the buffer is full, the call will block until it is cleared. So this would imply its ok to call k within a thread, unless I am reading this wrong. What do you think?
&nbsp;
