[pskmail] push2talk race condition in relation to PSKMail ??
- From: "remi.chateauneu@xxxxxxxxx" <remi.chateauneu@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx, fldigi alpha <fldigi-alpha@xxxxxxxxxxxxxxxx>, "fldigi-devel@xxxxxxxxxxxxxxxx" <fldigi-devel@xxxxxxxxxxxxxxxx>
- Date: Thu, 22 Mar 2012 23:15:37 +0000
Hi All,
I try to chase a possible bug which might be related to the activation
of the PTT in the context of the ARQ server, and I saw this:
$ grep push2talk src/*/*cxx | grep -w set
src/misc/arq_io.cxx:
REQ_SYNC(&PTT::set, push2talk, true);
REQ_SYNC(&PTT::set, push2talk, false);
src/trx/trx.cxx:
push2talk->set(true);
push2talk->set(false);
push2talk->set(true);
push2talk->set(false);
This means that the function PTT::set can be called in two different
threads:
- Transmit thread: functions trx_trx_transmit_loop and trx_tune_loop
- ARQ thread, function ParseMode
The function PTT::set calls hamlib_set_ptt which works basically this way:
void hamlib_set_ptt(int ptt)
{
LockMutex
setPtt
IfErrorThenLeavesPttWithoutUnlocking
UnlockingMutex
}
A possible error is that:
* If Hamlib had a problem setting the PTT then it will leave without
unlocking the mutex.
* If later on, a thread tries to set the PTT, it will just hang, waiting
for the mutex to be unlocked.
So I have two questions:
* Could you please confirm than when the problem happens, one thread is
frozen ?
* Is it possible that for any reason, the PTT did not work, just once ?
* Did someone saw in the logfile a message containing the string: "Rig
PTT" ?
Many thanks for any information.
Whatever the answer is, I think this can be considered as a therotical
bug at least, so I will suggest a fix.
If someone is interested, a good way to prove this is to trigger a ptt
problem (Unplugging the cable ? Manually setting the PTT ?)
Sincerely hope it helps.
R
Other related posts:
- » [pskmail] push2talk race condition in relation to PSKMail ?? - remi.chateauneu@xxxxxxxxx
