Before calling any ‘generator’ functions in a standalone application, you must initialise the kdb+ internal memory system. (It is done automatically when you open a connection to other kdb+ processes.) Without making a connection, use khp(“”,-1);
“Be aware that if a reference count is >0, you should very likely not change the data stored in that object as it is being referenced by another piece of code which may not expect the change. In this case, create a new copy of the object, and change that.”
I think we need to make this clearer in the docs that joins (ja,jk,..) assume a ref count of 0. I can’t think of a scenario where you would want to suffer your observations - appending to a common object until a copy is forced at a capacity threshold.
an atom to a list: K ja(K*,V*);
a string to a list: K js(K*,S);
another K object to a list: K jk(K*,K);
another K list to the first: K jv(K*,K); The join functions assume there are no other references to the list , as the list may need to be reallocated during the call.
and thank you to Antonio, who helped to investigate the behavior yesterday.
Looks like it is necessary to very carefully using RC of the struct and do some kind of control of relocation with manual copy of the rc (if necessary).
I mean that the copy-on-write does not happens in C-code, are there any easy way to make it in C-API, except manually?
BTW: Do I understand correct that the copy-on-write does not happen all the times?, because another way we would have a copy-on-write every ,:, which is quite heavy. And we would have copy-on-write every insertion a new row to a table, and the table does not loose the links to the vector.
We see here copy-on-change, everything looks ok, except that we lost initial top1 - how to know about it in C code and call r0 on it?
And more important question: this is part of table’s structure, but looks like adding to the table do not cause copy-on-write every change + mixed list does not loose pointer to relocated structure - which is also not behavior of the example.
ok, so just create the table, ensure that nothing references the elements inside it directly other than the table itself, such that all elements in the table have ref count 0. e.g.
J j=42;
K names=ktn(KS,2);kS(names)[0]=ss(“col1”);kS(names)[1]=ss(“col2”);
K t=xT(xD(names,knk(2,ktn(KS,0),ktn(KJ,0))));
Then, if you want to reference the table from some other code for whatever reason, use
If you want t1 to reference t and then also be able to append to t without updating t1 (i.e. copy on write), you will have to manually copy t and the contents into a new table prior to appending to t.
Alternatively, if you are writing a shared library to be loaded into kdb+, you can lean on q to do this via k(0,…).