[Hamlib-developer] CW sending is broken again

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

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.

-- 

73

n3gb