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.
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.