Hi Márcio,

> We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?

Which SLAC systems are still running 4-18?  That is a very old release, and there have been a number of fixes since then, some of which were particularly targeted at SLAC/LCLS.

These are the major fixes from the release notes that affect drvAsynIPPort and timestamps (which were done for SLAC/LCLS).

I am rather doubtful that a cherry-pick is going to work since there have been so many changes since R4-18.

R4-27

drvAsynIPPort

Added the option to automatically close the port when there is a read timeout. This was done by changing the syntax of the drvAsynIPConfigure command from
drvAsynIPPortConfigure("portName","hostInfo",priority,noAutoConnect,noProcessEos) to 
drvAsynIPPortConfigure("portName","hostInfo",priority,noAutoConnect,userFlags)
userFlags: bit-wise ORed:

• Bit 0 is USERFLAG_NO_PROCESS_EOS. If 0 then asynInterposeEosConfig is called specifying both processEosIn and processEosOut.
• Bit 1 is USERFLAG_CLOSE_ON_READ_TIMEOUT. If 1 then the (TCP) socket will be closed when read() returns a timeout.
• Bit 2--31 are reserved, set to zero.

This change is backwards compatible since bit 0 is the same as the previous noProcessEos. Thanks to Torsten Bogershausen for this change.

R4-22

drvAsynIPPort

Fixed a bug in calling poll(). Previously the status return from poll() was not being checked; it was assumed that when poll() returned the port either had new data or had timed out. This is not correct, because poll() can return prematurely with errno=EINTR if a Posix signal occurs before data is received or the timeout expires. This can happen, for example, when the Posix high-resolution timer routines (timer_create, etc.) are used in the IOC. The Prosilica vendor library uses the Posix timer routines, and there were problems using asyn IP ports in IOCs that were also running Prosilica cameras. The problem was fixed by calling poll() again if it returns EINTR and the desired timeout time has not expired since poll() was first called.

Added support for AF_UNIX sockets on systems that provide them.

asynDriver

Added support functions for setting timestamps in asyn port drivers. These can be used to set the timestamp when the port driver received data. The driver can then set the asynUser->timeStamp field to this value for all input records on read and callback operations. Records that have TSE=-2 will have this timestamp. There is support for registering a user-supplied function to provide the timestamp, which will override the default source that just calls epicsTimeGetCurrent().

R4-21

asynDriver

Restored the original versions of pasynManager->lockPort and unlockPort that were used in asyn prior to R4-14. These versions just call epicsMutexLock and epicsMutexUnlock. In R4-14 these versions were replaced with versions that queued requests to lock the port. The R4-14 versions fixed a problem with the interfaces/asynXXXSyncIO functions, but it has become clear that the original versions are useful in some circumstances. The change was done as follows:

• The lockPort and unlockPort functions in R4-20 were renamed to pasynManager->queueLockPort and queueUnlockPort.
• The interfaces/asynXXXSyncIO functions were all changed to call the queueLockPort and queueUnlockPort, so they function identically to how they have since R4-14.
• The versions of lockPort and unlockPort that existed prior to R4-14 were restored to pasynManager.

Changed the report() function so that if details<0 then asynManager does not print information for each device (address). It calls pasynCommon->report(-details) in this case so driver report functions will not be affected.

Changed the asynTrace print, printIO, vprint, vprintIO functions so they use EPICS_PRINTF_STYLE. This causes the GCC (version 3.0 and higher) and clang compilers to check the agreement of format strings with function arguments when using asynPrint() and asynPrintIO(), just as they do with printf(). This is very helpful in finding errors, and uncovered a number in asyn itself, which have been fixed.

Mark

Hello, Mark.

Probably it will work very well in our case. I will try this here and return to you as soon as I have a result. Thank you for this!

We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?

Thank you again,