EPICS Core-talk mailing list

Build failed: pva2pva 1.0.16

AppVeyor via Core-talk — Mon, 09 Mar 2026 21:39:53 GMT

Subject:	Build failed: pva2pva 1.0.16
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Mon, 09 Mar 2026 21:39:53 +0000

Build pva2pva 1.0.16 failed

Commit db7fa63d91 by Andrew Johnson on 3/9/2026 12:22 PM:
Replace GH ci-scripts-build.yml from pvData

Configure your notification preferences

Build failed: pva2pva 1.0.68

AppVeyor via Core-talk — Tue, 10 Mar 2026 01:33:12 GMT

Subject:	Build failed: pva2pva 1.0.68
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 10 Mar 2026 01:33:12 +0000

Build pva2pva 1.0.68 failed

Commit 2fc7130abc by Andrew Johnson on 3/6/2026 5:05 PM:
Replace epicsThreadExitMain() with spin-loop

Configure your notification preferences

Build failed: pva2pva 1.0.71

AppVeyor via Core-talk — Tue, 10 Mar 2026 01:34:14 GMT

Subject:	Build failed: pva2pva 1.0.71
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 10 Mar 2026 01:34:14 +0000

Build pva2pva 1.0.71 failed

Commit 2fc7130abc by Andrew Johnson on 3/6/2026 5:05 PM:
Replace epicsThreadExitMain() with spin-loop

Configure your notification preferences

Build failed: pva2pva 1.0.17

AppVeyor via Core-talk — Tue, 10 Mar 2026 06:47:37 GMT

Subject:	Build failed: pva2pva 1.0.17
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 10 Mar 2026 06:47:37 +0000

Build pva2pva 1.0.17 failed

Commit 1ef9a0ab8d by Andrew Johnson on 3/9/2026 2:16 PM:
Replace epicsThreadExitMain() with spin-loop

Configure your notification preferences

Build failed: pva2pva 1.0.68

AppVeyor via Core-talk — Tue, 10 Mar 2026 07:36:22 GMT

Subject:	Build failed: pva2pva 1.0.68
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 10 Mar 2026 07:36:22 +0000

Build pva2pva 1.0.68 failed

Commit 2fc7130abc by Andrew Johnson on 3/6/2026 5:05 PM:
Replace epicsThreadExitMain() with spin-loop

Configure your notification preferences

Build failed: pva2pva 1.0.68

AppVeyor via Core-talk — Tue, 10 Mar 2026 15:04:56 GMT

Subject:	Build failed: pva2pva 1.0.68
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 10 Mar 2026 15:04:56 +0000

Build pva2pva 1.0.68 failed

Commit 2fc7130abc by Andrew Johnson on 3/6/2026 5:05 PM:
Replace epicsThreadExitMain() with spin-loop

Configure your notification preferences

Build failed: pva2pva 1.0.69

AppVeyor via Core-talk — Wed, 11 Mar 2026 22:20:56 GMT

Subject:	Build failed: pva2pva 1.0.69
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Wed, 11 Mar 2026 22:20:56 +0000

Build pva2pva 1.0.69 failed

Commit 40612aaebb by Andrew Johnson on 3/11/2026 3:04 PM:
Merge pull request #63 from anjohnson/clang-warnings

Configure your notification preferences

Build failed: pva2pva 1.0.72

AppVeyor via Core-talk — Wed, 11 Mar 2026 22:55:55 GMT

Subject:	Build failed: pva2pva 1.0.72
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Wed, 11 Mar 2026 22:55:55 +0000

Build pva2pva 1.0.72 failed

Commit 40612aaebb by Andrew Johnson on 3/11/2026 3:04 PM:
Merge pull request #63 from anjohnson/clang-warnings

Configure your notification preferences

Build failed: pvDataCPP 1.0.72

AppVeyor via Core-talk — Wed, 18 Mar 2026 10:13:10 GMT

Subject:	Build failed: pvDataCPP 1.0.72
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Wed, 18 Mar 2026 10:13:10 +0000

Build pvDataCPP 1.0.72 failed

Commit ec43e93fce by Jeremy Lorelli on 3/18/2026 6:07 AM:
Add -S option to pvget/pvmonitor to stringify byte arrays

Configure your notification preferences

Build failed: pvDataCPP 1.0.72

AppVeyor via Core-talk — Wed, 18 Mar 2026 17:24:30 GMT

Subject:	Build failed: pvDataCPP 1.0.72
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Wed, 18 Mar 2026 17:24:30 +0000

Build pvDataCPP 1.0.72 failed

Commit ec43e93fce by Jeremy Lorelli on 3/18/2026 6:07 AM:
Add -S option to pvget/pvmonitor to stringify byte arrays

Configure your notification preferences

Build failed: pvDataCPP 1.0.72

AppVeyor via Core-talk — Wed, 18 Mar 2026 20:25:59 GMT

Subject:	Build failed: pvDataCPP 1.0.72
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Wed, 18 Mar 2026 20:25:59 +0000

Build pvDataCPP 1.0.72 failed

Commit ec43e93fce by Jeremy Lorelli on 3/18/2026 6:07 AM:
Add -S option to pvget/pvmonitor to stringify byte arrays

Configure your notification preferences

Build failed: pvDataCPP 1.0.72

AppVeyor via Core-talk — Thu, 19 Mar 2026 02:36:50 GMT

Subject:	Build failed: pvDataCPP 1.0.72
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Thu, 19 Mar 2026 02:36:50 +0000

Build pvDataCPP 1.0.72 failed

Commit ec43e93fce by Jeremy Lorelli on 3/18/2026 6:07 AM:
Add -S option to pvget/pvmonitor to stringify byte arrays

Configure your notification preferences

Build failed: pvAccessCPP 1.0.151

AppVeyor via Core-talk — Fri, 20 Mar 2026 01:59:31 GMT

Subject:	Build failed: pvAccessCPP 1.0.151
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Fri, 20 Mar 2026 01:59:31 +0000

Build pvAccessCPP 1.0.151 failed

Commit 742e286f1f by Jeremy Lorelli on 3/19/2026 7:44 PM:
Add -S option to pvget/pvmonitor to stringify byte arrays

Configure your notification preferences

Build failed: pvAccessCPP 1.0.35

AppVeyor via Core-talk — Tue, 07 Apr 2026 04:34:56 GMT

Subject:	Build failed: pvAccessCPP 1.0.35
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 07 Apr 2026 04:34:56 +0000

Build pvAccessCPP 1.0.35 failed

Commit c67926561e by Andrew Johnson on 4/6/2026 6:06 PM:
Potential fix for testChannelAccess tests

Configure your notification preferences

Build failed: pvAccessCPP 1.0.152

AppVeyor via Core-talk — Tue, 07 Apr 2026 06:32:30 GMT

Subject:	Build failed: pvAccessCPP 1.0.152
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 07 Apr 2026 06:32:30 +0000

Build pvAccessCPP 1.0.152 failed

Commit 345da0d5d5 by Andrew Johnson on 4/6/2026 11:06 PM:
Potential fix for testChannelAccess tests

Configure your notification preferences

Build failed: pvAccessCPP 1.0.152

AppVeyor via Core-talk — Tue, 07 Apr 2026 19:35:19 GMT

Subject:	Build failed: pvAccessCPP 1.0.152
From:	AppVeyor via Core-talk <core-talk at aps.anl.gov>
To:	core-talk at aps.anl.gov
Date:	Tue, 07 Apr 2026 19:35:19 +0000

Build pvAccessCPP 1.0.152 failed

Commit 345da0d5d5 by Andrew Johnson on 4/6/2026 11:06 PM:
Potential fix for testChannelAccess tests

Configure your notification preferences

Re: callbackRequestDelayed question

Mark Rivers via Core-talk — Sun, 14 Jun 2026 23:51:27 GMT

Subject:	Re: callbackRequestDelayed question
From:	Mark Rivers via Core-talk <core-talk at aps.anl.gov>
To:	"Johnson, Andrew N." <anj at anl.gov>, Mark Rivers <rivers at cars.uchicago.edu>
Cc:	"core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date:	Sun, 14 Jun 2026 23:51:27 +0000

Hi Andrew,

I reported in November 2025 issues with callbackRequestDelayed returning essentially immediately for delays less that 0.01 second.

I am happy to report that this works fine in base 7.0.10 on Linux and Windows.

This is the output on Linux:

epics> sleepTest1

epicsThreadSleepQuantum=0.010000

epicsThreadSleep: requested sleep time = 0.000010, actual=0.000084

epicsThreadSleep: requested sleep time = 0.000050, actual=0.000105

epicsThreadSleep: requested sleep time = 0.000100, actual=0.000152

epicsThreadSleep: requested sleep time = 0.000500, actual=0.000555

epicsThreadSleep: requested sleep time = 0.001000, actual=0.001055

epicsThreadSleep: requested sleep time = 0.002000, actual=0.002055

epicsThreadSleep: requested sleep time = 0.005000, actual=0.005055

epicsThreadSleep: requested sleep time = 0.010000, actual=0.010055

epicsThreadSleep: requested sleep time = 0.020000, actual=0.020057

callbackRequestDelayed: requested delay time = 0.000010, actual=0.000031

callbackRequestDelayed: requested delay time = 0.000050, actual=0.000118

callbackRequestDelayed: requested delay time = 0.000100, actual=0.000168

callbackRequestDelayed: requested delay time = 0.000500, actual=0.000531

callbackRequestDelayed: requested delay time = 0.001000, actual=0.001068

callbackRequestDelayed: requested delay time = 0.002000, actual=0.002068

callbackRequestDelayed: requested delay time = 0.005000, actual=0.005069

callbackRequestDelayed: requested delay time = 0.010000, actual=0.010070

callbackRequestDelayed: requested delay time = 0.020000, actual=0.020070

This is the output on Windows:

epics> sleepTest1

epicsThreadSleepQuantum=0.015625

epicsThreadSleep: requested sleep time = 0.000010, actual=0.000058

epicsThreadSleep: requested sleep time = 0.000050, actual=0.000543

epicsThreadSleep: requested sleep time = 0.000100, actual=0.000539

epicsThreadSleep: requested sleep time = 0.000500, actual=0.000959

epicsThreadSleep: requested sleep time = 0.001000, actual=0.001459

epicsThreadSleep: requested sleep time = 0.002000, actual=0.002478

epicsThreadSleep: requested sleep time = 0.005000, actual=0.005469

epicsThreadSleep: requested sleep time = 0.010000, actual=0.010385

epicsThreadSleep: requested sleep time = 0.020000, actual=0.020423

callbackRequestDelayed: requested delay time = 0.000010, actual=0.000039

callbackRequestDelayed: requested delay time = 0.000050, actual=0.000135

callbackRequestDelayed: requested delay time = 0.000100, actual=0.000646

callbackRequestDelayed: requested delay time = 0.000500, actual=0.001012

callbackRequestDelayed: requested delay time = 0.001000, actual=0.001668

callbackRequestDelayed: requested delay time = 0.002000, actual=0.002551

callbackRequestDelayed: requested delay time = 0.005000, actual=0.005533

callbackRequestDelayed: requested delay time = 0.010000, actual=0.010505

callbackRequestDelayed: requested delay time = 0.020000, actual=0.020168

The sscan record currently enforces a minimum delay of epicsThreadSleepQuantum, which does not make sense for Linux or Windows. I changed sscanTecord.c to remove that restriction except for vxWorks. I can now run the sscanRecord with delays below 1 ms, and hence do fly scans faster than 1000 points/s.

I am making a PR for my new version.

Thanks,

Mark

From: Core-talk on behalf of Mark Rivers via Core-talk
Sent: Wednesday, November 12, 2025 3:11 PM
To: Johnson, Andrew N.
Cc: core-talk at aps.anl.gov
Subject: RE: callbackRequestDelayed question

Hi Andrew,

I moved my test routing inside an IOC and initialized the CALLBACK structure to 0 with ={0}. The routine now runs fine, but I am getting a result I did not expect. I have attached the new version of the code.

epics> sleepTest1

epicsThreadSleepQuantum=0.010000

epicsThreadSleep: requested sleep time = 0.000010, actual=0.000065

epicsThreadSleep: requested sleep time = 0.000050, actual=0.000103

epicsThreadSleep: requested sleep time = 0.000100, actual=0.000154

epicsThreadSleep: requested sleep time = 0.000500, actual=0.000553

epicsThreadSleep: requested sleep time = 0.001000, actual=0.001057

epicsThreadSleep: requested sleep time = 0.002000, actual=0.002055

epicsThreadSleep: requested sleep time = 0.005000, actual=0.005056

epicsThreadSleep: requested sleep time = 0.010000, actual=0.010035

epicsThreadSleep: requested sleep time = 0.020000, actual=0.020058

callbackRequestDelayed: requested delay time = 0.000010, actual=0.000027

callbackRequestDelayed: requested delay time = 0.000050, actual=0.000028

callbackRequestDelayed: requested delay time = 0.000100, actual=0.000021

callbackRequestDelayed: requested delay time = 0.000500, actual=0.000022

callbackRequestDelayed: requested delay time = 0.001000, actual=0.000024

callbackRequestDelayed: requested delay time = 0.002000, actual=0.000023

callbackRequestDelayed: requested delay time = 0.005000, actual=0.000021

callbackRequestDelayed: requested delay time = 0.010000, actual=0.005067

callbackRequestDelayed: requested delay time = 0.020000, actual=0.015070

Note that epicsThreadSleep sleeps for about 55 microseconds longer than requested, which may just be the overhead of epicsTimeGetCurrent after the sleep.

However, callbackRequestDelayed returns within about 25 microseconds for all delays less than 0.01 seconds, and returns .005 seconds too soon for .01 and .02 second delays. This is disappointing, I was hoping it would have a behavior similar to epicsThreadSleep, so we can get accurate short delays. Do you understand this?

Thanks,

Mark

From: Johnson, Andrew N.
Sent: Wednesday, November 12, 2025 11:37 AM
To: Mark Rivers
Subject: Re: callbackRequestDelayed question

Hi Mark,

Ahh, so this is outside of an IOC. Yes you will need to call callbackInit() first, there’s no lazy init code built into that as it’s normally only used within an IOC where initialization is handled for you. There might be other things you need to do as well if that doesn’t prove sufficient, the function iocBuild_1() in base/modules/database/src/ioc/misc/iocInit.c is where I would look for the other things the IOC sets up.

HTH,

- Andrew

Complexity comes for free, Simplicity you have to work for.

On 11/11/25, 6:23 PM, "Mark Rivers" <rivers at cars.uchicago.edu> wrote:

This Message Is From an External Sender

This message came from outside your organization.

Hi Andrew,

Thanks for the quick response.

I added calls to callbackSetPriority and callbackSetUser, but it still crashes.

I have attached my test program. It is designed to test the minimum usable times for epicsThreadSleep() and callbackRequestDelayed().

This is what I get when I run it with gdb.

Starting program: /home/epics/support/CARS/bin/linux-x86_64/sleepTest1

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

[New Thread 0x7ffff77ff640 (LWP 252197)]

[Thread 0x7ffff77ff640 (LWP 252197) exited]

epicsThreadSleepQuantum=0.010000

epicsThreadSleep: requested sleep time = 0.000010, actual=0.000067

epicsThreadSleep: requested sleep time = 0.000050, actual=0.000104

epicsThreadSleep: requested sleep time = 0.000100, actual=0.000153

epicsThreadSleep: requested sleep time = 0.000500, actual=0.000554

epicsThreadSleep: requested sleep time = 0.001000, actual=0.001054

epicsThreadSleep: requested sleep time = 0.002000, actual=0.002062

epicsThreadSleep: requested sleep time = 0.005000, actual=0.005059

epicsThreadSleep: requested sleep time = 0.010000, actual=0.010056

epicsThreadSleep: requested sleep time = 0.020000, actual=0.020056

[New Thread 0x7ffff7bfd640 (LWP 252198)]

[New Thread 0x7ffff77ff640 (LWP 252199)]

[New Thread 0x7ffff7afc640 (LWP 252200)]

[New Thread 0x7ffff6ffe640 (LWP 252201)]

[New Thread 0x7ffff6dfd640 (LWP 252202)]

Thread 1 "sleepTest1" received signal SIGSEGV, Segmentation fault.

0x00000000004b6f57 in epicsTimerStartDelay (pTmr=0x5b0000006e, delaySeconds=1.0000000000000001e-05) at ../timer/epicsTimer.cpp:258

258 pTmr->start ( *pTmr, delaySeconds );

Missing separate debuginfos, use: dnf debuginfo-install boost-system-1.75.0-10.el9.x86_64 glibc-2.34-168.el9_6.14.x86_64 libstdc++-11.5.0-5.el9_5.x86_64 ncurses-libs-6.2-10.20210508.el9.x86_64 readline-8.1-4.el9.x86_64

(gdb) bt

#0 0x00000000004b6f57 in epicsTimerStartDelay (pTmr=0x5b0000006e, delaySeconds=1.0000000000000001e-05) at ../timer/epicsTimer.cpp:258

#1 0x00000000004368ad in main (argc=, argv=) at ../sleepTest1.cpp:45

Note that I am calling callbackRequestDelayed() outside the context of an IOC. Do I need to first call callbackInit()?

My motivation for this test is the sscan record. It forces the values for the positioner delay and detector delay to be no smaller than epicsThreadSleepQuantum(). I believe this is a serious limitation on the performance of fly scans, and so I would like to investigate removing that restriction. On Linux epicsThreadSleepQuantum is 10 ms, but I can get reliable epicsThreadSleep() for much shorter times. I want to see if that is also true for callbackRequestDelayed(), since that is what the sscan record uses.

Thanks,

Mark

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Tuesday, November 11, 2025 5:58 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Subject: Re: callbackRequestDelayed question

Hi Mark,

You may need to call callbackSetPriority(PRIORITY, PCALLBACK) as well unless you allocate the epicsCallback structure using calloc(). The callback’s priority is used as an index into an array and must be in the range 0-2. I could see that an uninitialized value there might cause a crash, so that might be your issue. Looking at the code in modules/database/src/ioc/db/callback.c it looks like it gets checked, but there might be some paths where it doesn’t.

I can look further tomorrow if you don’t find an answer before then.

- Andrew

Complexity comes for free, Simplicity you have to work for.

On 11/11/25, 5:35 PM, "Mark Rivers" <rivers at cars.uchicago.edu> wrote:

This Message Is From an External Sender

This message came from outside your organization.

Hi Andrew,

I am trying to use callbackRequestDelayed. The calls I am making are:

CALLBACK delayCallback;

callbackSetCallback(myCallback, &delayCallback);

callbackRequestDelayed(&delayCallback, requestedTime);

My program compiles with no warnings. But it crashes at run-time with this:

#0 0x00000000004b6f47 in epicsTimerStartDelay (pTmr=0x5b0000006e, delaySeconds=1.0000000000000001e-05) at ../timer/epicsTimer.cpp:258

#1 0x00000000004368a5 in main (argc=, argv=) at ../sleepTest1.cpp:44

Is there something I need to do to initialize the timer for the delayed callback or something?

Thanks,

Mark

Re: callbackRequestDelayed question

Michael Davidsaver via Core-talk — Mon, 15 Jun 2026 00:15:56 GMT

Subject:	Re: callbackRequestDelayed question
From:	Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
To:	Mark Rivers <rivers at cars.uchicago.edu>
Cc:	"core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date:	Sun, 14 Jun 2026 17:15:56 -0700

On 6/14/26 4:51 PM, Mark Rivers via Core-talk wrote:

Hi Andrew,

I reported in November 2025 issues with callbackRequestDelayed returning essentially immediately for delays less that 0.01 second.

I am happy to report that this works fine in base 7.0.10 on Linux and Windows.

cf. github issue 106 and PR 704. There is even a release notes entry!

https://github.com/epics-base/epics-base/blob/c5d1668895094bea44aee7655c386b2d9192cfa9/documentation/RELEASE-7.0.10.md?plain=1#L373-L389

...
... I changed sscanTecord.c to remove that restriction except for vxWorks. ...

This tracks well with the change to epics-base.

Re: callbackRequestDelayed question

Mark Rivers via Core-talk — Mon, 15 Jun 2026 01:14:50 GMT

Subject:	Re: callbackRequestDelayed question
From:	Mark Rivers via Core-talk <core-talk at aps.anl.gov>
To:	Michael Davidsaver <mdavidsaver at gmail.com>
Cc:	"core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date:	Mon, 15 Jun 2026 01:14:50 +0000

There is even a release notes entry!

Yes, that is what prompted me to re-do the test.

However, the release notes just say "However this also resulted in timers expiring slightly [earlier than requested]".

It is not clear from that statement that it fixed the problem of callbackRequestDelayed returning immediately for delays less than epicsThreadQuantum/2. IMO that is more than "slightly earlier than requested", since it made delays less than 10 ms on Linux unavailable.

Mark

From: Michael Davidsaver
Sent: Sunday, June 14, 2026 7:15 PM
To: Mark Rivers
Cc: core-talk at aps.anl.gov ; Johnson, Andrew N.
Subject: Re: callbackRequestDelayed question

On 6/14/26 4:51 PM, Mark Rivers via Core-talk wrote:

Hi Andrew,

I reported in November 2025 issues with callbackRequestDelayed returning essentially immediately for delays less that 0.01 second.

I am happy to report that this works fine in base 7.0.10 on Linux and Windows.

cf. github issue 106 and PR 704. There is even a release notes entry!

https://github.com/epics-base/epics-base/blob/c5d1668895094bea44aee7655c386b2d9192cfa9/documentation/RELEASE-7.0.10.md?plain=1#L373-L389

...

... I changed sscanTecord.c to remove that restriction except for vxWorks. ...

This tracks well with the change to epics-base.

Re: callbackRequestDelayed question

Michael Davidsaver via Core-talk — Mon, 15 Jun 2026 19:09:21 GMT

Subject:	Re: callbackRequestDelayed question
From:	Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
To:	Mark Rivers <rivers at cars.uchicago.edu>
Cc:	"core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date:	Mon, 15 Jun 2026 12:09:21 -0700

On 6/14/26 6:14 PM, Mark Rivers wrote:

There is even a release notes entry!

Yes, that is what prompted me to re-do the test.

However, the release notes just say "However this also resulted in timers expiring slightly [earlier than requested]".

It is not clear from that statement that it fixed the problem of callbackRequestDelayed returning immediately for delays less than epicsThreadQuantum/2. IMO that is more than "slightly earlier than requested", since it made delays less than 10 ms on Linux unavailable.

Also, "This affects several facilities which use epicsTimer, including record delays". Still, I take your point. Mentioning the local level "epicsTimer" name does not convey the full list of effected APIs and features. And "slightly earlier" is a fuzzy statement.

I am anyway happy to hear that this long-standing issue has been resolved for you.

Mark

From: Michael Davidsaver
Sent: Sunday, June 14, 2026 7:15 PM
To: Mark Rivers
Cc: core-talk at aps.anl.gov ; Johnson, Andrew N.
Subject: Re: callbackRequestDelayed question

On 6/14/26 4:51 PM, Mark Rivers via Core-talk wrote:

Hi Andrew,

I reported in November 2025 issues with callbackRequestDelayed returning essentially immediately for delays less that 0.01 second.

I am happy to report that this works fine in base 7.0.10 on Linux and Windows.

cf. github issue 106 and PR 704. There is even a release notes entry!

https://github.com/epics-base/epics-base/blob/c5d1668895094bea44aee7655c386b2d9192cfa9/documentation/RELEASE-7.0.10.md?plain=1#L373-L389

...

... I changed sscanTecord.c to remove that restriction except for vxWorks. ...

This tracks well with the change to epics-base.