Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Mon, 2 Sep 2019 08:57:12 -0700

The main concern I see is locking and callbacks.  Current calls to asTrap*() happen
without holding the record lock.  The asTrap* functions can't be moved entirely into
dbChannelPut() without changing this.

This concern is also why I can't trivially add asTrap*() calls to QSRV.  The PVA to DBR
data type conversion is currently happening under the record lock.  (Not required,
just convenient)

If this were to change then some answer/plan would need to be made to address the
possibility of deadlocks and slowdown.  Maybe it is enough to say that asTrap handlers
should never be locking records or blocking?  

Also, I hadn't noticed asTrapWritePvt::lock before.  So many singleton locks...

On 9/2/19 4:39 AM, Johnson, Andrew N. wrote:
> I don’t think that would be trivial even for just the Trap Write calls, the dbChannel layer doesn’t have access to the asClientPVT context pointer. For the other interfaces dbChannel doesn’t know anything about the client that is requesting access. I suspect the current arrangement may be the simplest, but I haven’t looked at it too closely.
> 
> - Andrew
> 
> 
>> On Sep 2, 2019, at 9:08 AM, Zimoch Dirk (PSI) via Core-talk <[email protected]> wrote:
>>
>> On Mon, 2019-09-02 at 07:00 +0000, Zimoch Dirk (PSI) via Core-talk wrote:
>>> Shouldn't PVA be implemented one level lower in dbChannel instead of in each network protocol?
>>
>> Sorry typo, I meant: Shouldn't access security be implemented in dbChannel?
>> Dirk
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System