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.
