We have an Alum 47-10 that we need to operate with exposures of 1-10s throughout the night. Our Linux host (CentOS 8) with the dlapi 1.4 library has a problem with cpu load rising over several hours, until it's using 100% cpu. To isolate the problem (in my own code? in CCfits? in dlapi?) I took the very simple dlapi v1.4 sample program, and added nothing but a while loop around the exposure control and image download. I also made a variant in which the body of the while loop is moved into a separate function. Both showed the same behavior: very little memory growth over time, but the cpu load invariably rises continuously. (I should mention that we removed the shutter from the camera, and as far as the camera is concerned, we are taking continous darks.) The dlapi v1.4 sample program polls the camera status continuously until it's ready for download. In case this polling was triggering the problem, I tried preceding the poll loop with a sleep for the exposure time + known camera overhead time, which reduced the number of polls from ~300 to ~2. It made no difference: the cpu load still grew at about the same rate. Is this a known problem with the Linux dlapi 1.4? If so, do you know if it's fixed in dlapi 2.1? And finally, do you have a release date planned for Linux 2.1? thank you, -will
Long story short: it may be a bug in 1.4 that an architectural change in 2.x would have fixed, but I'm not sure. It depends on pthread usage and the like. We don't have a release date on 2.1+ for Linux because of issues with third-party vendor software we've been trying to resolve. I'm about to leave on vacation for 2 weeks. I'll be back in the office on July 18th. As a workaround if you're able until we can resolve this: try encapsulating your core image acquisition algorithm into an executable and call that instead of keeping the connection alive. It's definitely not our *intended* use case, but it would get around the processing usage leak.
