Hi Ervin, finally I find time to answer. Sorry for the delay.
Am Sat, 13 Oct 2018 18:15:22 +0200 schrieb Ervin Hegedüs <airw...@gmail.com>: > > There is still one problem with your solution which you should sort > > out: fldigi_get_log_call() is called from background_process which > > runs as a separate thread parallel to the logging front end > > function logit(). That may be ok for just polling fldigi and > > displaying the received text in the rtty window. But for > > manipulating hiscall and displaying the according country > > information it may result in problems as both - your function and > > callinput() may manipulate the same data. > > yes, it's clear for me (now...). > > > Furthermore neither getctydata() nor searchlog() are checked to be > > threadsafe, so calling it from the background thread may be > > problematic. > > as I see, both function called from different threads - without > fldigi_get_log_call(), so we have to review anyway. > Ok, have not seen it. Thanks, I will look for that. > > I have added the code as is to get forward with the 1.3.1 release > > but you should sort out the problems in next time. > > ok - what should we do? After first and quick review I thought we > can make a new function in callinput.c, called sethiscall(), > which waits a string, and sets the hiscall. All other function in > different threads collects the callsign in a local buffer, and > call this function. This new function should rentrant and thread > safe... any idea? > I think there is a better way. Copy the call in fldigi_get_log_call() into an intermediate buffer and set a flag. During callinput() we pick that up and bring it to hiscall. The access to the buffer can be protected by a mutex and so made thread safe. The advantage in these scheme is that we have control when we change hiscall. Otherwise it may be possible that fldigi_get_log_call() does change it during some unrelated operation (e.g. writing the last QSO to disk or similar). 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
