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

[Black M. <mdb...@ya...>]

Yes I know -- that send_morse was not designed to work with other calls being active.
I'll have to work on some thread protection.
Mike W9MDB

 

    On Tuesday, February 20, 2024 at 12:17:50 PM CST, George Baltz <geo...@gm...> wrote:  
 
  
All I have is one more with -vvvv, 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