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
we nolonger check the bytes in the socket with an ioctl
o removed incomingBytesPresent virtual function from inBufClient interface
because we nolonger check the bytes in the socket with an ioctl
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
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 in casStrmClient :: processMsg () I forced status to S_cas_success at a couple
of loop exits. There is probably not a bug because the variable is initialized to
this value and the loop termintaes if the status isnt this value nevertheless
the corrected code is more robust to future changes.
o fixed a benign issue in casStrmClient :: processMsg () where if the user
sends a message to big for EPICS_MAX_ARRAY_SIZE and there is
currently no room in the output buffer then the user will not receive
a diagnostic message. With the patch the message will be sent later once
there is space.
casDGClient :: inBufBytesPending reflecting the fact that we nlonger use
a socket ioctl to check how many bytes are pending in the sockets
input queue
o casDGClient::outBufBytesPresent renamed to
casDGClient::outBufBytesPending for consistency with inBufBytesPending
(not a bug but messy)
o added optimization where we only check as many registered fd's
on the list as select tells us are active in its status
o added code to clear all of the fd_set if select returns an error
(in practice this would not cause a bug other than some extra activity
that would immediately self terminate when it clear the flag in the fd_set,
and also we dont see the error message printed when select returns an error)
Apparently the GeSys dynamic linker doesn't maintain C semantics.
I'm afraid that this behaviour is likely to cause lots of other problems,
but for now I'll apply the patch since it's harmless.
Jeff Hill