<div>I have submitted a ticket #1979</div>
<div> </div>
<div>Best Regards,</div>
<div> Daniel Bäck<br><br></div>
<div class="gmail_quote">On Nov 8, 2007 5:19 PM, Tamas Szekeres <<a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Daniel,<br><br>__declspec(thread) is a Microsoft VC specific so it cannot used as an<br>universal solution. Moreover it works in DLLs only when those DLLs are
<br>bound to the executable, and will not work for those loaded with<br>LoadLibrary().<br><br>In this particular case it would be reasonable to allocate the buffer<br>in the stack at the beginning of every function using these variables.
<br><br>Alternatively there's a fairly platform neutral TLS implementation in<br>gdal that can also be used.<br><br>You might want to submit a ticket with this issue.<br><br><br>Best regards,<br><br>Tamas<br><br><br><br>
2007/11/8, Daniel <<a href="mailto:daniel112b@gmail.com">daniel112b@gmail.com</a>>:<br>
<div>
<div></div>
<div class="Wj3C7c">> Hello,<br>><br>> I have run into some threading issues accessing a .tab file from multiple<br>> threads. Each thread has it's own OGRDataSource so the OGRDataSource objects<br>> won't get accessed from more than one thread at a time. The GDAL faq says:
<br>><br>> "In particular for the situation where many threads are reading from GDAL<br>> datasets at once should work as long as no two threads access the same<br>> GDALDataset object at the same time"
<br>><br>> Is the same thing true for OGR? ( or at least in the sense that it is<br>> supposed to be). I think i have tracked down the problem in this particular<br>> case to CPLSPrintf. The static buffers it is using is declared as:
<br>><br>><br>><br>> static CPL_THREADLOCAL char<br>> gszCPLSPrintfBuffer[CPLSPrintf_BUF_Count][CPLSPrintf_BUF_SIZE];<br>><br>> static CPL_THREADLOCAL int gnCPLSPrintfBuffer = 0;<br>><br>> but CPL_THREADLOCAL is by default defined to nothing, a long time ago (23/5
<br>> 2005) CPL_THREADLOCAL was defined to declspec(thread) in cpl_config.h.vc<br>> which should have made them thread local. But that was changed a month later<br>> or so. Was there a particular reason for that? I havn't used thread local
<br>> storage much myself so i don't know how good it works or if it differs alot<br>> between different compilers. I havn't tried to define CPL_THREADLOCAL myself<br>> yet to see if it works but i'll hope i'll get time to do that.
<br>><br>> My problems occur while i'm trying to extract the styling info and i end up<br>> with an empty style string when running multiple threads.<br>><br>><br>><br>> Regards,<br>><br>> Daniel Bäck
<br>><br></div></div>> _______________________________________________<br>> Gdal-dev mailing list<br>> <a href="mailto:Gdal-dev@lists.maptools.org">Gdal-dev@lists.maptools.org</a><br>> <a href="http://lists.maptools.org/mailman/listinfo/gdal-dev" target="_blank">
http://lists.maptools.org/mailman/listinfo/gdal-dev</a><br>><br></blockquote></div><br>