Tthread-local geos context #164
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
To the actual code change: instead of allocating new geos contexts I'm just reusing the same thread-local contexts via |
Open
| let mut cy = 0.; | ||
|
|
||
| let ret = GEOSSegmentIntersection_r( | ||
| ctx.as_raw(), |
There was a problem hiding this comment.
Is it needed here? Couldn't with_context be called inside GEOSSegmentIntersection_r methods directly?
There was a problem hiding this comment.
GEOSSegmentIntersection_r is a GEOS C API, how would that work?
There was a problem hiding this comment.
Ah it's a function. My bad, then that answers my question.
|
This is super cool! Just one question and then seems ready for me to go. |
GuillaumeGomez
approved these changes
Dec 3, 2024
|
Again, great improvement, thanks! |
|
Thank you :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is follow-up of my previous issue #141 and also reaction to #160. (I don't think there is a memory leak, but this PR does lower memory footprint of every geometry by little more than 1kB as that is roughly the size of geos context, which would be reused with my PR and not allocated for every geometry.)
I see geos context as just an implementation detail of propagating error messages from c++ geos exceptions through geos c api in reentrant way. To address questions in #141: I dont't think the context is useful from user's point of view and I would say it is better/simpler to not have it in public api at all. I also think that context should not be a property of geometry for the same reason (and because unnecessarily used memory). And also I don't see it useful to be able to set own error handler as the context is already used to propagate geos errors to
GResult. The original c++ geos api has nothing like the context and also python geos wrappershapelyis using geos context only as an internal implementation detail and is not accessible to users.Another reason for this PR is that geos context is not thread-safe (it's not
Sync), so this PR makes things correct. Although right now it seems that the worst case is possibly corrupted error message which is not severe problem really, but still.So this is my suggestion :)