If vxiName is specified as "inst" then the driver incorrectly says that it does not block.
If asynRecord is attached to a port that does not implement asynOctet, then asynRecord crashes of it attempt to send/receive a message.
The next release gaurantees that when queueRequest is called:
The RPC library on Mac OS X 10.3.3 does not handle device timeouts properly and may cause core dumps. A bug report has been filed with Apple. A workaround is to use the GNU glibc RPC/XDR routines.
Attempting to change the trace file to "stdout" does not work becuase vxWorks has per-task standard output streams.
When building with EPICS Base R3.14.6 or greater, comment out the epicsInterruptibleSyscall.h and epicsInterruptibleSyscall.c lines in asyn/Makefile:
@@ -19,10 +19,10 @@ SRC_DIRS += $(ASYN)/asynDriver INC += asynDriver.h INC += epicsInterruptibleSyscall.h -INC += epicsString1.h +#INC += epicsString1.h asyn_SRCS += asynManager.c asyn_SRCS += epicsInterruptibleSyscall.c -asyn_SRCS += epicsString1.c +#asyn_SRCS += epicsString1.c SRC_DIRS += $(ASYN)/asynGpib INC += asynGpibDriver.h
The RPC library on Mac OSD 10.3.3 does not handle device timeouts properly and may cause core dumps. A bug report has been filed with Apple. A workaround is to use the GNU glibc RPC/XDR routines.
If a user callback calls a low level driver with an infinite or very long timeout, there is no way to make the call terminate. Is there a generic way to abort the call?
Does not support GPIB specific functions.
This needs to be implemented for asynDriver.
Think about creating generic support for connecting to EPICS records.
Consider generic support for various network protocals: Modbus, etherIP, etc.