> On Oct 6, 2021, at 4:23 PM, Greg Troxel <g...@lexort.com> wrote:
>
>
> Paul Ramsey <pram...@cleverelephant.ca> writes:
>
>> I found the relevant CMake line, and only the unit tests should be ending
>> up with a link dependency to pthreads. So don't declare the library itself
>> as having a pthread dependency. (Maybe next release, when we get all jiggy
>> with multi-threaded performance work, ha ha ha)
>> P
>>
>> --- from cmakelists.txt
>> find_package(Threads)
>> target_link_libraries(test_geos_unit PRIVATE geos geos_c Threads::Threads)
>
> Interesting. I wonder if the tests should avoid threads if the library
> isn't built with threads.
No, the tests are saying "what if a multi-threaded application needed to call
this library". So this is a useful exercise.
> It seems obvious (maybe I'm wrong) that if a library is not built with
> threads, then a threaded program that uses it must ensure that only one
> library call is happening at any given time, either by calling it only
> from one specific thread, or having a "call into geos" mutex.
That's essentially what happens in the "reentrant API", the threads each keep a
piece of "GEOS state" local to themselves and pass it into their function
calls, so they avoid stomping on each other for things like the default
geometryfactor or error messages.
> I found that the geos library did get linked with -lpthread. I will
> reproduce that and see if I can figure out why, after moving to rc3.
Hm, that's quite odd, the cmake line only applies Threads::Thread to the
test_geos_unit target, not to the library targets.
P
>
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
