Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I read the following in the doc.: "GT.M currently does not handle
TP support across multiple call-in invocations. Make sure all
external call C functions, that invoke call-in functionality are not
fenced within a TSTART/TCOMMIT boundary"...
Can someone tell me why there is no transactional support through
call-in interface ?
Any way to get around this issue ?
Narayanan S Rajamani
Just to be sure, transactions ARE supported with the call-in interface in the usual case. It is only multiple call-ins that are not supported.
The rule is that call-ins are not allowed if you are already in a TSTART transaction.
Examples that are supported
1) main.m has not done TSTART and invokes callout.c which in turn invokes callin.m that does TSTART/TCOMMIT.
2) main.m has done a TSTART but before doing a TCOMMIT it invokes callout.c that does NOT do any call-ins.
Example that is NOT supported
1) main.m has done a TSTART and before doing a TCOMMIT it invokes callout.c which in turn invokes callin.m (i.e. does call-ins).
The reason why this is not supported is that in case the transaction needs to be rolled-back/restarted while it is in callin.m, in addition to rolling back all M activity in callin.m and main.m (until the TSTART) GT.M also has to roll back the C stack corresponding to callout.c and then reexecute it all (in case of a restart) which might cause undesirable effects (like memory and file descriptor leaks etc.) in case callout.c was not coded to be reexecutable. GT.M has no control of the C environment which is why it simply does not support it.
Do you have an example scenario that falls under the NOT supported category?