Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send and Sync #141

Open
kellerkindt opened this issue Sep 20, 2022 · 6 comments
Open

Send and Sync #141

kellerkindt opened this issue Sep 20, 2022 · 6 comments

Comments

@kellerkindt
Copy link

What is the status about Send and Sync?
There is no explicit unimpl note, but due to the raw-pointers, it is also not auto-impled on Proj.
Is it safe to move the Proj instance between threads and have shared calls to .project?

If so, what about providing the impl:

unsafe impl Sync for Proj {}
unsafe impl Send for Proj {}

If not, what about clarifying it in the docs / README.

Background: I would like to load and parse the proj-definition once and call the projection from different places in the application.

@urschrei
Copy link
Member

Context creation is cheap and e.g. creating one per thread using Pro::new mirrors the underlying libproj ProjCtx, which is intended to be created per thread.

I'm not sure whether it would be safe to pass the wrapped raw pointer around, but it's unlikely that we'll try to do so without some evidence of a performance concern – the string slice used to create the context can be created immutably and shared / moved without concern, which provides a guarantee that instances created using it will perform identically.

@kellerkindt
Copy link
Author

kellerkindt commented Sep 20, 2022

Yeah, it just makes storing it in an otherwise Send + Sync (and readonly) struct really hard (impossible?) or it needs to be instantiated before every use.

@frewsxcv
Copy link
Member

frewsxcv commented Jan 2, 2023

My understanding, and I very well might be wrong, is that so long as we're always fetching the error from the context (and not the global context), then it should be Send, I think?

@frewsxcv
Copy link
Member

frewsxcv commented Jan 7, 2023

Opened a PR for Send #147

@kellerkindt
Copy link
Author

kellerkindt commented Feb 21, 2023

This issue might be impossible to implement due to how the errors are retrieved (potential conditions on Sync) and the context being bound to the current thread at creation time (while Send / moving between threads can occur at any time)...?

@TomFryersMidsummer
Copy link
Contributor

Having Send would make writing asynchronous code with Proj much easier.

Could PJ_CONTEXT pointers be moved out of the Proj and ProjBuilder structs into thread-local variables? It would seem to fit well with the advice in the Proj documentation:

It is recommended to create one threading context per thread used by the program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants