Re: [Hamlib-developer] [Hamlib/Hamlib] 890ed1: Change morse_data_handler from LOCK to rig_lock as...

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

The LOCK macro is not for general thread safety.
It's just there for the main Hamlib thread.
I updated the comment about it to show that.

Morse is using rig_lock directly so always asks for level 1.








On Monday, December 2, 2024 at 05:25:18 PM CST, George Baltz <geo...@gm...> wrote: 






On 12/2/24 18:10, Black Michael wrote:
> The depth is  need to avoid deadlock on recursion.
>
> So anybody coming in at level 1 has to grab the lock.

But that means it's useless for general thread safety.  Another thread 
calling rig_<whatever> will have incremented depth (in ENTERFUNC) so it 
won't call rig_lock().

How about PTHREAD_MUTEX_RECURSIVE?



>
> Mike W9MDB
>
>
>
>
>
>
>
>
> On Monday, December 2, 2024 at 04:00:35 PM CST, George Baltz <geo...@gm...> wrote:
>
>
>
>
>
>
> On 12/2/24 16:12, Black Michael wrote:
>> Mutexes do address general thread safety.
> Yeah, but LOCK() is not (just) a mutex. Consulting an unprotected
> variable(depth) to decide on locking leads to all sorts of races,
> mismatches, and other random errors.
>
> No other facet of programming is so absolutely ruled by Murphy's Law.
>
>> They are just a pain when you don't have thread-safe code designed from scratch.
> You can say that again.
>
>> Mike W9MDB