3.16: More/better TPRO context data

Bug #1428339 reported by Andrew Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
EPICS Base
Triaged
Wishlist
Andrew Johnson

Bug Description

In 3.15 and later, setting TPRO results in dbAccess calling dbServerClient() to obtain printable information about the thread that is causing processing to occur. This calls each registered dbServer in turn asking it to provide context data if it is responsible for the current thread (rsrv responds with "ca:<username>@<host>"). It should be possible to improve the information available so that scanOnce() and maybe other queues don't lose the triggering context.

If the scanOnce subsystem registered as a dbServer, when it gets asked to queue a record with TPRO set it could call dbServerClient() and save the context information from its caller along with the record, then respond with that data when its dbServer::client() routine is called by dbAccess from within the onceTask.

scanOnce is used by dbCa to process records with CP and CPP links when their monitors fire. The dbCa task would also have to register as a dbServer so it could provide the necessary information (this would require a threadPrivate variable, scanLinkOnce() is run from the CA client callback routines), or we could add an alternative API to scanOnceCallback() which provides the context information to be queued (no threadPrivate variable needed, but less flexible). This context data should only be stored when TPRO is set though, we shouldn't be allocating memory and generating the context string unnecessarily.

Tags: codeathon
Andrew Johnson (anj)
tags: added: codeathon
Changed in epics-base:
assignee: nobody → Andrew Johnson (anj)
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.