I’ll answer this myself: When esl_mutex_t is created in esl_mutex_create(), attribution “PTHREAD_MUTEX_RECERSIVE” is set. This attribution allows mutex is locked for several times without unlock in the same thread. So there is no dead lock issue for esl_execute() But I still meet another dead lock between main thread (sending ESL cmd) and ESL event process thread, is there any constrain for esl interface usages in *INBOUND* mode under multi-thread?
>>>
esl_execute() When I read the implementation of the code, is there any possibility to dead lock as following? esl_execute() +-->esl_send_recv /esl_send_recv_timed(_handle, _cmd, 0) +--> esl_mutex_lock(handle->mutex); <<<<< lock for 1st time +--> esl_recv_event_timed(handle, ms, 0, &handle ->last_sr_event) +--> esl_recv_event() +----> esl_mutex_lock(handle->mutex); <<<<<< lock for 2nd time, but preview one is not unlock