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

Multithreading #53

Closed
christophlingg opened this issue Jul 1, 2015 · 14 comments
Closed

Multithreading #53

christophlingg opened this issue Jul 1, 2015 · 14 comments

Comments

@christophlingg
Copy link

Thanks for providing RTree for Python!

I was wondering if rtree can be used in a multithreaded context?

@songololo
Copy link

+1

@marfago
Copy link

marfago commented Jul 16, 2015

Actually seems it is not possible. At least with recent versions.

libspatialindex/libspatialindex#71

@hobu
Copy link
Member

hobu commented Jul 17, 2015

libspatialindex is not threadsafe and Rtree does not do thread safety. It is something that could be done, but it would take a lot of meticulous work to achieve.

@christophlingg
Copy link
Author

Ok I can comprehend that concurrent writing and reading may cause problems, but are read-only accesses safe?

@marfago
Copy link

marfago commented Jul 19, 2015

In my experience it seems it is not.
In a project I use https://github.com/collective/collective.geo.index, wich is based on RTree. For each search it instantiates a new instance of RTree and now and then it crashes with segmentation fault. I solved this issue moving the rtree to a global variable (just one instance). Not sure it can help.

@christophlingg
Copy link
Author

That's strange because I am accessing one rtree from multiple threads (only read), and so far i did not encounter any problems.

@snorfalorpagus
Copy link
Member

@christophlingg Race conditions can be like that. It may be that certain issues are only triggered under high(er) loads.

@hobu
Copy link
Member

hobu commented Jul 20, 2015

Ok I can comprehend that concurrent writing and reading may cause problems, but are read-only accesses safe?

No. libspatialindex, especially as used through the C API like Rtree does, is not thread safe. If it is working for you, it is most likely due to luck.

@christophlingg
Copy link
Author

Now I know I need to fix something ;-) Thanks to your feedback I can do this before it crashes!

@hobu
Copy link
Member

hobu commented Jul 20, 2015

The most pressing issue is probably the one described in libspatialindex/libspatialindex#71 especially in regards to the C API.

If you put some aggressive locking around things in python land, you are likely to be reasonably protected. The issues most likely manifest themselves in regard to error messages, and the error stack of the C API of libspatialindex not being protected in any way.

@marfago
Copy link

marfago commented Sep 17, 2015

I'm working with a single thread instance of the index, but it daily crashes!
Can anyone suggest what exactly should be "protected" in python?

@hobu
Copy link
Member

hobu commented Sep 17, 2015

Can anyone suggest what exactly should be "protected" in python?

Protect any access you do to libspatialindex with a mutex and lock accordingly.

@marfago
Copy link

marfago commented Oct 26, 2015

@hobu :Adding mutex or lock did not work for me. Moreover, also using different processes working on the same index file ends up in segmentation fault.

@hobu
Copy link
Member

hobu commented Oct 26, 2015

libspatialindex has a thread safety issue. Someone needs to develop a clear case that demonstrates the issue so it can be resolved.

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

5 participants