getDataSizeElement of gdd container returns the number of sub fields.
It has to be called on the "value" field. This fix has already been done
in monitorReponse.
(this is an issue I introduced when writing the patch where IO
and subscription update events are maintained on seperate
and independent queues). The issue does not exist in an
EPICS base release.
in the out buf. The send will not arm if the out buf is empty
o when receiving the io blocked state notify callback always reactivate the
receive if space is available
when simultaneouly in flow control mode and also asynchronous io
postponed mode.
o simplified the status from the process func because callers should
not need to know how many messages have been sent
when simultaneouly in flow control mode and also asynchronous io
postponed mode.
o simplified the status from the process func because callers should
not need to know how many messages have been sent
responseIsPending, and pValueRead whenever removing a
message from the stream
o eliminated error prone reuse of status variables
o dont allow service to postpone IO when no IO is pending against the target
o be extra careful not to do things twice when send blocked or IO postponed
event latency, and allows events to flow if we are blocked due to the
service postponing an IO operation. This was a bug fix.
o call processMessage directly from the IO completion callback
that restarts when in an IO postponement state. This makes the logic easier
to understand and maintain, but isnt a functional change
o call processMessage directly from the receive callback.
This makes the logic easier to understand and maintain, but isnt
a functional change
o call processMessage directly from the send callback.
This makes the logic easier to understand and maintain, but isnt
a functional change
o removed the eventFlush function
independent of whether receive bytes are pending or not. This improves
event latency, and allows events to flow if we are blocked due to the
service postponing an IO operation. This was a bug fix.
o when finishing processing input activate a send if more than one half
of the TCP buffering would be used. In the past the send was not activated
until either the send buffer was full or the receive buffer (including any
bytes waiting in the socket) was empty. This could cause latency and
performance issues because send receive piplining would not occur if they
have very large buffers due to a large EPICS_CA_MAX_ARRAY_SIZE.
o always activate a send if we enter a service is postponing IO state. Users
would probably prefer to receive past responses and not wait until the
postponed IO initiates.
o casStrmClient::inBufBytesAvailable renamed to
casStrmClient:: inBufBytesPending reflecting the fact that we nlonger use
a socket ioctl to check how many bytes are pending in the sockets
input queue
o casStrmClient::outBufBytesPresent renamed to
casStrmClient::outBufBytesPending for consistency with inBufBytesPending
o removed the eventFlush function
o removed sendBlocked flag
o call processMessage directly from the IO completion callback
that restarts when in an IO postponement state. This makes the logic easier
to understand and maintain, but isnt a functional change
o call processMessage directly from the receive callback.
This makes the logic easier to understand and maintain, but isnt
a functional change
o call processMessage directly from the send callback.
This makes the logic easier to understand and maintain, but isnt
a functional change
zimoch
Andrew Johnson
wang_x1