send_periodic with non-None duration sends one extra message before stopping

[grant-allan-ctct]

Describe the bug

If we pass a duration argument to send_periodic, the message transmissions don't stop at the time specified. One extra message is sent.

To Reproduce

To see this, call send_periodic with period argument and duration arguments such that the duration is not simply a multiple of the period. For example, with duration of 2 seconds, specify a period of 0.6 seconds, or 0.8 seconds. In both cases, the final transmitted message will be at 2.4 seconds (which is 0.6 x 4 repeats, or 0.8 x 3 repeats), which is well past the expiry of the 2 seconds duration.

Expected behavior

The messages should stop transmitting when the duration time elapses (give or take a little wiggle-room).

Additional context

We seem to have effectively an off-by-one error that's arising from the way that the ThreadBasedCyclicSendTask has things ordered inside its while loop:

1. send a message
2. check whether it's time to stop yet
3. wait for another period

I'm thinking that this means that the final message can be later than the duration by an amount of time up to the size of the period.

OS and version: Windows10
Python version: 3.11.6
python-can version: 4.3.0
python-can interface/s (if applicable):

Sample output where devices on a bus are asked periodically to claim addresses:

With duration 2 seconds, period 0.6 seconds

Timestamp:       15.414987    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       16.016019    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       16.615183    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       17.215543    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       17.816031    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1

Time of final transmission after first transmission = 17.816031 - 15.414987 = 2.401044 seconds

With duration 2 seconds, period 0.8 seconds

Timestamp:       19.160761    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       19.961824    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       20.761057    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1
Timestamp:       21.561177    ID: 18eafffe    X Tx                DL:  3    00 ee 00                    Channel: 1

Time of final transmission after first transmission = 21.561177 - 19.160761 = 2.400416 seconds

[Tbruno25]

What a detailed bug report! Thanks for providing all the info.

Seems valid to me. Re-arranging the _run method appears to fix it.

I opened a draft PR.