Re: [Hamlib-developer] CW sending is broken still

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

Won't make a difference to the operation.

The root problem is that there is NO locking between 
morse_data_handler() and the rest of hamlib.  LOCK() will never call 
rig_lock(), and even if it did rs->multicast is always NULL.

rig_init() sets rs->depth to 1.  Since ENTERFUNC increments depth, the 
test in the LOCK macro will never succeed,  so rig_lock() isn't called.

Initializing rs->depth to 0 at least calls rig_lock(), which then does 
nothing, as the multicast buffer is never allocated.  It should be set 
in multicast_init(), but there is only one call to it in the code base, 
and that is in the '#ifdef TEST' part of multicast.c.

As I said, multithreading in hamlib needs re-working.

On 2/18/25 5:10 PM, Black Michael wrote:
> In kenwood.c try changing this line
>
>          case RIG_MODEL_TS890S:
>              SNPRINTF(morsebuf, sizeof morsebuf, "KY2%s", m2);
>
>              Change the 2 to a space.
>              SNPRINTF(morsebuf, sizeof morsebuf, "KY %s", m2);
>
>
>
>
>
>
>
>
>
>
> On Monday, February 17, 2025 at 07:24:36 PM CST, George Baltz <geo...@gm...> wrote:
>
>
>
>
>
> Still doesn't work with multicast turned on.  Today's testing done via
> rigctl.
>
> Two attachments - debugging patch+fix for gcc error(needs upper case W),
> and STDERR output from:
>
> rigctl -m 2041 -r /dev/pts/2 -vvvvvv
> --setconf=multicast_data_addr=224.0.0.1 2>/tmp/err_verb.txt
>
> Near the bottom of the trace it shows both calls to rig_lock() (around
> the call to kenwood_send_morse()) took the early return.
>
>
> On 2/17/25 6:21 PM, Black Michael wrote:
>> --set-conf=multicast_data_addr=224.0.0.1
>>
>>     So does it work when multicast is turned on?
>>
>> How are you sending data to hamlib?
>>
>> Mike W9MDB
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Monday, February 17, 2025 at 01:11:31 PM CST, George Baltz <geo...@gm...> wrote:
>>
>>
>>
>>
>>
>> Last weekend was the ARRL DX CW weekend, and I fired up my
>> peanut-whistle to try for a couple of new ones on 10M.  Used tlf and
>> latest 4.7-git hamlib.  It worked for a while, then it started
>> missing/dropping messages, timeouts, rig link errors,  or hard lockups.
>> Restarting the program was the only way back to operational.  My
>> condolences to any station I left hanging.
>>
>> This morning I started investigating, using simts890.  Was not happy
>> with what I found.  Somehow, in turning off multicast, rig_lock() (and
>> hence LOCK()) was turned into a NOP.  It bailed out in the first
>> conditional - rs->multicast == NULL.  So no coordination at all between
>> morse_data_handler() and the rest of the world, resulting in clobbered
>> messages, untimely rig_flush(), etc.
>>
>> How should this be fixed?  Having m_d_h() use a lock added by multicast
>> may be expedient, but hardly intuitive.  And it really doesn't help with
>> the multi-threaded application problem.
>>
>> The whole threading approach in hamlib needs to be analyzed, both for
>> internal and external threads.  There are at least 4 mutexes for various
>> interactions, some of which are really only used on one side, and none
>> of them cover the whole range of possible conflicts.
>>
>> Comments and advice, please.
>>