Hi Bill,
Your proposed course of action looks good. An alternative to your item
(4) would be for the decoding routines write directly to std out when
called from the standalone program. This seems simpler to me; it would
need only a flag to indicate whether being called from within WSJT-X or
from the command-line program.
As for the timer routine: those calls can be useful when we're
optimizing for speed, but I think it's not worth a lot of design time to
make them all-purpose. We will probably once more want a way to
determine where most of the execution time is being spent. That should
be possible in a number of fairly simple ways.
-- Joe
On 12/17/2015 6:46 PM, Bill Somerville wrote:
> On 17/12/2015 14:42, Joe Taylor wrote:
>> On a related matter: have you given up your effort aimed at compiling
>> the decoders into wsjt-x, as opposed to a separate jt9 process? You
>> may have noticed that the "fast" modes -- JTMSK, ISCAT, and Fast JT9
>> -- are decoded in WSJT-X itself, with a separate thread started with a
>> QtConcurrent::run() call. My hangup in bringing the jt9[.exe] stuff
>> into WSJT-X has been that it would need a way to send decoding
>> results, as obtained, back to the GUI thread. I haven't spent the time
>> to work out how to (in effect) send Qt "signals" from the Fortran code.
> Hi Joe & all,
>
> having ploughed through the changes needed to move the data and
> parameter passing mechanism away from Fortran common blocks between the
> wsjtx and jt9 programs and refreshed my memory on how it all hangs
> together; the following seems to be a reasonable approach to calling the
> decoders directly from wsjtx:
>
> 1) Write a version of lib/decoder.f90 in C++ using Qt for the
> multi-threaded part,
> 2) change the decoders to take a callback function that will be called
> with each decode result as it occurs,
> 3) eliminate any remaining thread unsafe code and OpenMP from the
> decoders (See below about timer module issues),
> 4) write Fortran callback functions that can be used in the jt9, jt65
> and similar standalone programs to maintain that functionality,
> 5) write C/C++ callback functions that inject the decode results as they
> occur into wsjtx for display and other processing.
>
> OpenMP would not be used in wsjtx as the above Qt threading would do the
> same job.
>
> The existing lib/decoder.f90 can be retained with some modifications to
> pass the Fortran style decode callbacks, OpenMP could be retained for
> this but the timer module might cause some complications. We might need
> two different lib/timer.f90 implementations, one for OpenMP and one for
> Qt threading. An alternative might be to implement the timer calls as a
> callback function so the caller could decide how to deal with MT issues.
>
> Comments, objections, other alternative suggestions?
>
> 73
> Bill
> G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
