chrislit at crosswire.org
Wed May 22 04:05:44 MST 2013
On 5/22/2013 3:26 AM, Robert Hunt wrote:
> Yes, it seems that Chris did indeed fix the script so that my supplied
> minimal test case no longer causes the program to require a manual halt.
> Unfortunately though, processing of that particular USFM field wasn't my
> main issue. The main issue seems to be that the program does not fail
> gracefully if a processing fault is hit in the USFM to OSIS conversion.
Indeed... I only fixed the bug that you reported, not the bug you didn't
report. ;) If you can provide a bug report with some input that
predictably produces erroneous output or gets stuck, I can fix the bug.
> So I still have to manually halt the script to try to track down the
> next USFM processing error. (I suspect the main problem that I'm
> concerned about is in the multiprocessing aspect of the script.)
I'm not sure what could concern you about a multithreaded application.
In this case, the script gives each USFM file to a separate thread for
processing and does them in parallel, attempting to keep all of your
processor's logical cores fully utilized. You can always turn
multithreading off (i.e. set the thread count to 1), but it really won't
change anything other than the running time.
More information about the sword-devel