Call-in to M code that specifies a call-in table
Final Release Note
Description
In threaded applications that call-in to YottaDB, the potential exists for a race condition. Between the time that a thread sets the call-in table and the time that it calls YottaDB using the table, another thread can potentially change the call-in table. The solution is a set of functions that call in to YottaDB and include the table specification in the call.
Draft Release Note
The functions
ydb_status_t ydb_tab_ci(uintptr_t handle, const ydb_char_t* c_call_name, ...);
int ydb_tab_ci_t(uintptr_t handle, uint64_t tptoken, ydb_buffer_t *errstr, const char *c_rtn_name, ...);
ydb_status_t ydb_tab_cip(uintptr_t handle, ci_name_descriptor *ci_info, ...);
int ydb_tab_cip_t(uintptr_t handle, uint64_t tptoken, ydb_buffer_t *errstr, const char *c_rtn_name, ...);
are equivalent to the functions ydb_ci(), ydb_ci_t(), ydb_cip() and ydb_cpi_t() respectively, except that they unconditionally use the call-in table specified by the handle
parameter, and leave the currently selected call-in table unchanged. The handle
parameter is provided by the ydb_ci_tab_open() / ydb_ci_tab_open_t() functions previously used to open the call-in table.
A workaround was to use ydb_incr_s() / ydb_incr_st() to atomically increment a global variable before calling ydb_ci_tab_switch() / ydb_ci_tab_switch_t() and proceed only if the value is a pre-determined value like 1, and atomically decrement it if the value is different or after the subsequent call to M code. [#953]