Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Thu, 24 Jan 2019 10:54:37 -0800

On 1/24/19 9:56 AM, Johnson, Andrew N. via Core-talk wrote:
> If there's a fix for this I suspect it belongs in dbDbLink.c's processTarget() routine. In the actions for the case 'else if (psrc->putf)' we know that pdst->pact is true so the destination record is busy, but maybe if pdst->putf is also true we should *not* set pdst->rpro, since it might be in our calling chain. Unfortunately pdst->putf might be true because it's in someone else's calling chain (in which case we probably *should* set pdst->rpro), but we currently have no way of distinguishing those two cases.

I think the fundamental issue is that PACT!=0 can mean two things.
Either async processing is in progress, or synchronous (recursive)
processing is in progress.

Seems like the best course is for dbProcess() and processTarget()
to keep track of which records are being recursed into.

> I could see of a way around this by storing an identifier in the PUTF and RPRO fields which would let us see that (I'd make the PUTF and RPRO fields into DBF_LONG and use an atomic counter to generate a unique ID for each source put).

I was thinking of using a stack address, or maybe epicsThread*, from the thread which is doing
the processing.  Not really fundamentally different from a global counter, though maybe easier
to debug.  This would be set and cleared by dbProcess().

I'm not sure about hijacking the existing flag fields.  Maybe add a new field in dbCommonPvt?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System