[poppler] RFC: upstream optional threading support in pdftoppm for simple testing

Adam Reichold adamreichold at myopera.com
Sun Apr 7 07:31:52 PDT 2013


Hello,

Am 07.04.2013 16:13, schrieb Albert Astals Cid:
> El Dissabte, 6 d'abril de 2013, a les 17:43:54, Adam Reichold va escriure:
>> Hello,
>>
>> Am 06.04.2013 17:14, schrieb Albert Astals Cid:
>>> El Divendres, 5 d'abril de 2013, a les 21:43:28, Adam Reichold va 
> escriure:
>>>> Hello again,
>>>>
>>>> I was a bit in a rush at the first try. Sorry for that, I tidied it up
>>>> slightly.
>>>
>>> Maybe we should rename from UTILS_USE_THREAD to UTILS_USE_PTHREAD ?
>>>
>>> Or add a comment somewhere that we only support pthreads for now
>>> somewhere?
>>
>> I would be fine with both.
>>
>> Actually, since this is mostly meant for testing, I would be fine with
>> not making it accessible via autotools or CMake at all, i.e. just add
>> the definition to 'config.h' manually when and if we need it.
> 
> Makes sense to me, code-wise what's the difference between this and the code 
> Thomas posted in the threading bug? Do you think this is simpler/easier to 
> understand?

Yes, the difference is that I left out the Windows-specific part and
tried to keep it as simple as possible. For example, I think
synchronizing on the job queue is simpler than synchronizing on the
thread state. But of course, my implementation is not very efficient in
terms of performance, just sufficient for testing.

Best regards, Adam.

> Cheers,
>   Albert
> 
>>
>> Best regards, Adam.
>>
>>> Besides that it looks ok-ish in a quick look.
>>>
>>> Anyone has a comment?
>>>
>>> Cheers,
>>>
>>>   Albert
>>>>
>>>> Best regards, Adam.
>>>>
>>>> Am 05.04.2013 19:27, schrieb Adam Reichold:
>>>>> Hello everyone,
>>>>>
>>>>> To make it easier for us to test changes w.r.t. to threading, I would
>>>>> propose to commit a simple implementation of threading in 'pdftoppm' to
>>>>> master.
>>>>>
>>>>> The attached patch contains a very simple implementation that is not
>>>>> focused on maximal performance but should suffice to stress the locking
>>>>> inside Poppler's core. I opted to implement only the POSIX approach
>>>>> since I suppose POSIX systems are where most of us test and the code is
>>>>> hopefully simple and short enough not become a maintenance burden.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Best regards, Adam.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> poppler mailing list
>>>>> poppler at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>>
>>> _______________________________________________
>>> poppler mailing list
>>> poppler at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
> 


More information about the poppler mailing list