Re: [Hamlib-developer] CW sending is very broken...

[George B. <geo...@gm...>]

Trying again, without the attachment...

All I have is one more with -vvvv, NOT attached(10MB).

It's not the front end(FIFO), it's the call to rig->caps->send_morse 
from morse_data_handler that is the problem.

AFAIK tlf just calls the hamlib api; once it gets to rigctld everything 
is hamlib code.

On 2/20/24 12:02, Black Michael wrote:
> I need more logs with -vvvvv and -Z to see timing.
> I thought we had it thread safe but maybe tlf is doing something 
> different.
>
> I'll have to take a look at tlf.
>
>
> Mike W9MDB
>
>
>
>
> On Tuesday, February 20, 2024 at 10:50:46 AM CST, George Baltz 
> <geo...@gm...> wrote:
>
>
> ...but that may just be a symptom.
>
>
> Last weekend I operated a bit in the ARRL DX CW test - first CW contest
> since last February.  Setup was my TS-890S barefoot into a Buddipole and
> a 10M dipole, driven by a laptop running tlf with Hamlib 4.6-git.
>
> Worked fine for a while, then started getting no response to keyboard,
> followed by multiple copies of text being sent.  Saw some hamlib errors
> displayed in the tlf bottom line, but they vanished too quickly to
> remember. Then changed over to running rigctld and configuring tlf to
> use hamlib_dummy(#2) as rig.  Still getting flaky response and keying.
>
> So I added -vvv and captured the logs - some are attached.
>
> Looking at these, then at the code, it looks to me like the problem is
> much deeper than rig_send_morse - AFAICT none of the backend code is
> thread-safe, nor is the rig protocol itself. Having the main app thread,
> morse_data_handler, and other threads all calling the rig backends at
> the same time means they are stomping all over each other, and the rig
> responses may be consumed by the wrong requestor.
>
> In the short term, bypassing(reverting) the morse_data_handler would fix
> keying.  For the long term we need a real plan to make hamlib
> thread-safe.  This means defining the scope of the threads, what code
> needs protection, what are the effects on the application, how to do
> error recovery/logging, etc.  Making legacy code thread-safe is not easy.
>
> Comments, please, to the list.
>
> 73
>
> n3gb
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer