Aron Bierbaum wrote: > The only idea that I have off the top of my head is to use > threading.local in order to keep track of a handle for each thread > that calls any function in GEOS. I tried implementing something like > this quickly and ran into problems. Any other ideas?
Since I'm going to have to do the same for GeoDjango's bindings, I've been kicking around some ideas on how to do this -- and I also thought of something similar. I think this idea would work, but it's going to require some extensive implementation. Basically you'd have a global dict keyed by threading.currentThread() and a corresponding value be the GEOS context handle. However, you'd have to (have a way to determine whether you're running GEOS 3.1 or not and use the appropriate threading/non-threading function signature -- including dynamically insert the context handle into the GEOS C API function arguments. I'm wondering how much overhead this is and what the effect on performance would be -- but I haven't had time (and won't for the next several weeks) to mock up and try it out. >> Thread safety hasn't been a problem up to now, and we've hammered on >> it quite a bit. We're using PyDLL to load libgeos_c, which means the >> GIL isn't released. >> Yeah, it's a problem that's not seen until two routines enter the same critical areas in GEOS at the same time. For web apps the problem (segfaulting Apache/FCGI processes) becomes more apparent as traffic increases for the site. I consider it a serious problem. -Justin _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
