Some VxWorks BSPs close the stderr stream that the shell running
the startup script created and open a new one for the interactive
shell. This change makes pvtData.console==NULL mean use stderr
instead of storing the stderr value in pvtData.console at init.
This could be triggered if dbCaRemoveLink() is called on a link for
which there is an outstanding dbCaPutCallback().
Normally a dbCaPutCallback() callback routine is passed the associated
userPvt pointer as an argument, but in the event that dbCaRemoveLink()
gets used on the same link between the put and its completion callback,
the callback routine was being called with the link pointer as the
argument instead.
For all the existing Asyn Soft Channel device supports this is not a
problem as they all pass the link pointer as their userPvt argument, but
that won't necessarily always be the case.
Also updated the comments describing the process of removing links.
The main reason for this merge proposal is the change to "public" API functions.
Use atomic counter to resolve data race on threadsRunning in callback.
Split up callbackShutdown() and scanShutdown() into two phases *Stop() and
*Cleanup(). The *Stop() functions signal worker threads, and wait for them to
exit. The *Cleanup() functions actually reclaim global resources.
These two mechanisms have couplings which are quite complex. I/O Intr scans
involve both scan lists and callbacks.
From Benjamin Franksen:
There is one remaining problem with the order of includes in the build
rules for 3.14.12.5: configure/RULES_BUILD includes RULES_FILE_TYPE
(which in turn includes the cfg/RULES* from modules in the RELEASE file)
*after* including RULES.Db and RULES_JAVA. This makes it impossible to
override (pattern) rules in one of these files. Instead,
$(CONFIG)/RULES_FILE_TYPE should be included first.
Moved -m64 from ARCH_DEP_*FLAGS to OP_SYS_*FLAGS where it is on -x86.
Added GNU_TUNE_CFLAGS to -x86_64, adjust related comments
Added -D_FILE_OFFSET_BITS=64 to -x86 builds
This commit fixes a problem introduced in Bazaar commit 12658.
Local CA channels were seeing the data type of a channel as an
IOC-specific (dbFldTypes.h) type value instead of the CA type
value from db_access.h.
We introduce a pair of dbChannel*CAType() macros which convert
the dbChannel's dbr_field_type and final_type values into the
CA equivalent type values, and use these macros whenever the
CA encoded field type value is needed. This ensures that the
meaning of the dbChannel member fields never changes (in 3.14
the addr.dbr_field_type was overwritten with the converted
value when connected to by rsrv).
