[geos-devel] 3.10.0beta2

[Paul Ramsey]

> On Oct 6, 2021, at 4:23 PM, Greg Troxel <gdt at lexort.com> wrote:
> 
> 
> Paul Ramsey <pramsey at 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

>