In disconnectAllChannels mark channels as unassigned to any list
because in some unusual situations (abrupt shutdown) the channels are
not immediately assigned to another list.
o gnu compiler for windows doesnt support well dll exporting individual functions from a class
in debug builds so I switched to exporting the entire interface class in several places
o fixed several places in ca lib where include of epicsTimer.h wasnt properly ifdef'd so
that it is imported by ca header files
--- these issues were already fixed on cvs main trunk ---
While the cac dtor runs and waits for TCP circuit threads to exit,
new circuits could be opened by name resolution replies on existing
(still active) circuits.
Avoid this by setting a flag (lock being held) in the dtor, and
checking it in cac::transferChanToVirtCircuit.
The rsrv server is updated in this commit to deliver variable sized
waveforms in response to a zero length request, implementing an
extension to the v4 EPICS protocol tied to minor version 13.
The core of the changes are in read_reply, rsrv/camessage.c, which first
reserves packet space for the largest possible response, but then resizes
the packet according to how much data is actually returned from the
database.
In this commit the channel access client is modified to allow a zero
size request in a caget or camonitor call. This is passed through to
the corresponding CA_PROTO_READ_NOTIFY or CA_PROTO_EVENT__ADD message,
but only if the minor version of the protocol is >=13.
This commit also adds a new protocol test, CA_V413(), which detects a
server which claims to understand the new zero length request.
Finally, this commit prepares for a subtle change in the CA protocol.
A request for a zero length subscription or data request, which will
only be made for protocol version 4.13 and above, is interpreted as a
request for autosized data, where the intrinsic dynamic length of the
requested waveform should be returned.
With the synchronous ca_array_get() call there is no mechanism available
to pass back the size of the retrieved data if it is different from
the requested count, so the simplest thing is to ensure we don't
request autosizing data through this api.
The rsrv server is updated in this commit to deliver variable sized
waveforms in response to a zero length request, implementing an
extension to the v4 EPICS protocol tied to minor version 13.
The core of the changes are in read_reply, rsrv/camessage.c, which first
reserves packet space for the largest possible response, but then resizes
the packet according to how much data is actually returned from the
database.
In this commit the channel access client is modified to allow a zero
size request in a caget or camonitor call. This is passed through to
the corresponding CA_PROTO_READ_NOTIFY or CA_PROTO_EVENT__ADD message,
but only if the minor version of the protocol is >=13.
This commit also adds a new protocol test, CA_V413(), which detects a
server which claims to understand the new zero length request.
Finally, this commit prepares for a subtle change in the CA protocol.
A request for a zero length subscription or data request, which will
only be made for protocol version 4.13 and above, is interpreted as a
request for autosized data, where the intrinsic dynamic length of the
requested waveform should be returned.
With the synchronous ca_array_get() call there is no mechanism available
to pass back the size of the retrieved data if it is different from
the requested count, so the simplest thing is to ensure we don't
request autosizing data through this api.
* Pulled out tcpiiu::SearchDestTCP to have cac create the SearchDest independent from the TCP circuit
* Reorganized the relation between the SearchDestTCP and the TCP circuit:
- SearchDest stays always on the cac list
- TCP connection going down sets SearchDest inactive and SearchDestTCP's circuit member to NULL
- Next seach request creates the new TCP circuit and sets SearchDestTCP's member, but leaves SearchDest inactive
- Successful connect sets SearchDest active
* ReceiveThread releases the cac mutex before going to sleep in connect loop
o the flow control contig frame thresh should be based on max array size
o it appears that the wakeup mechanism for the send thread, who sends
the flow control on/off messages was broken
o looking at full buffers isnt a perfect detection scheme compared to
the simpler approach of just checking to see if bytes are pending in
the socket before calling recv
