Am 21.09.2014 um 18:29 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread
>
>
> No, maybe I explain it badly, with changes that I pushed yesterday, search
> works as expected, i.e. there are parallel searches started on all opened
> document without crash.
No, there are several search tasks running but all of their calls to the
DjVuLibre API are serialized, so they are not really running in parallel
but rather interleaved. And this is then also true for rendering which
is not an acceptable limitation.
Best regards, Adam.
> Best Regards,
> Razi.
>
> 2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:
>
>> Hello Razi,
>>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread, but not the issue since the
>> problem is most likely within the Windows of DjVuLibre as other
>> platforms can happily render or search pages of different documents and
>> hence contexts in parallel which is a performance improvement I would
>> not miss because of one problematic port. My suggestion was in any case
>> meant to isolate the problem so that we now know that the Windows
>> implemenation of DjVuLibre has a threading problem for text extraction
>> which the POSIX port does not seem to have. (Or our usage of the API is
>> wrong and it works on Linux by pure luck which have no indication for so
>> far.)
>>
>> Best regards, Adam.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1370540
>>
>> Title:
>> Search within multiple DjVu files.
>>
>> Status in qpdfview:
>> Incomplete
>>
>> Bug description:
>> Steps to reproduce:
>> 1- Open more than two DjVu that you know have the text you trying to
>> search.
>> 2- Write the string you want to search if search-line edit and use
>> SHIFT+Enter to start search within all opened documents.
>> 3- Crash!!
>> 4- There's no problem when at most one DjVu document is opened.
>>
>> Call stack from WinDbg:
>> ntdll!RtlpNtSetValueKey+0x12b
>> ntdll!RtlpNtSetValueKey+0x2914
>> ntdll!RtlpNtSetValueKey+0x31c5
>> ntdll!LdrSetAppCompatDllRedirectionCallback+0x11442
>> MSVCR100!free+0x1c
>> libdjvulibre!DJVU::GExceptionHandler::operator=+0x5e
>> libdjvulibre!miniobj_t::destroy+0xc
>> libdjvulibre!miniexp_symbol+0x564
>> libdjvulibre!ddjvu_document_get_outline+0x39b
>> libdjvulibre!ddjvu_document_get_outline+0x43d
>> libdjvulibre!ddjvu_document_get_outline+0x43d
>> libdjvulibre!ddjvu_document_get_pagetext+0x1c9
>> qpdfview_djvu!qt_plugin_instance+0x24b4
>> ntdll!RtlAllocateHeap+0xc6
>> QtCore4!QAbstractEventDispatcher::QAbstractEventDispatcher+0x39
>> qpdfview+0x18a16
>> QtCore4!QThread::setPriority+0x3a3
>> QtCore4!QString::toStdWString+0x1b3b
>> MSVCR100!endthreadex+0xe4
>> ntdll!RtlCreateMemoryZone+0x9b
>> ntdll!RtlCaptureContext+0xeb
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/qpdfview/+bug/1370540/+subscriptions
>>
>
>
Hello again,
Am 21.09.2014 um 18:29 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread
>
>
> No, maybe I explain it badly, with changes that I pushed yesterday, search
> works as expected, i.e. there are parallel searches started on all opened
> document without crash.
No, there are several search tasks running but all of their calls to the
DjVuLibre API are serialized, so they are not really running in parallel
but rather interleaved. And this is then also true for rendering which
is not an acceptable limitation.
Best regards, Adam.
> Best Regards, /bugs.launchpad .net/bugs/ 1370540 ValueKey+ 0x12b ValueKey+ 0x2914 ValueKey+ 0x31c5 CompatDllRedire ctionCallback+ 0x11442 DJVU::GExceptio nHandler: :operator= +0x5e miniobj_ t::destroy+ 0xc miniexp_ symbol+ 0x564 ddjvu_document_ get_outline+ 0x39b ddjvu_document_ get_outline+ 0x43d ddjvu_document_ get_outline+ 0x43d ddjvu_document_ get_pagetext+ 0x1c9 djvu!qt_ plugin_ instance+ 0x24b4 teHeap+ 0xc6 QAbstractEventD ispatcher: :QAbstractEvent Dispatcher+ 0x39 QThread: :setPriority+ 0x3a3 QString: :toStdWString+ 0x1b3b endthreadex+ 0xe4 MemoryZone+ 0x9b eContext+ 0xeb /bugs.launchpad .net/qpdfview/ +bug/1370540/ +subscriptions
> Razi.
>
> 2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:
>
>> Hello Razi,
>>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread, but not the issue since the
>> problem is most likely within the Windows of DjVuLibre as other
>> platforms can happily render or search pages of different documents and
>> hence contexts in parallel which is a performance improvement I would
>> not miss because of one problematic port. My suggestion was in any case
>> meant to isolate the problem so that we now know that the Windows
>> implemenation of DjVuLibre has a threading problem for text extraction
>> which the POSIX port does not seem to have. (Or our usage of the API is
>> wrong and it works on Linux by pure luck which have no indication for so
>> far.)
>>
>> Best regards, Adam.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https:/
>>
>> Title:
>> Search within multiple DjVu files.
>>
>> Status in qpdfview:
>> Incomplete
>>
>> Bug description:
>> Steps to reproduce:
>> 1- Open more than two DjVu that you know have the text you trying to
>> search.
>> 2- Write the string you want to search if search-line edit and use
>> SHIFT+Enter to start search within all opened documents.
>> 3- Crash!!
>> 4- There's no problem when at most one DjVu document is opened.
>>
>> Call stack from WinDbg:
>> ntdll!RtlpNtSet
>> ntdll!RtlpNtSet
>> ntdll!RtlpNtSet
>> ntdll!LdrSetApp
>> MSVCR100!free+0x1c
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> qpdfview_
>> ntdll!RtlAlloca
>> QtCore4!
>> qpdfview+0x18a16
>> QtCore4!
>> QtCore4!
>> MSVCR100!
>> ntdll!RtlCreate
>> ntdll!RtlCaptur
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>
>