SQLite3 and threads

[Mike Parker via Digitalmars-d-learn]

On 3/2/2015 4:20 PM, Vitalie Colosov wrote:
> Now it all makes sense. Thank you.
> Maybe it would make also some sense if I would have gotten some kind of
> exception trying to access the variable which was not populated by the
> running thread, instead of successfully getting empty string... so this
> would be observed easily during the testing, but perhaps there are some
> reasons for it being implemented the way it is, will keep learning.

No, it shouldn't throw an exception. There are good reasons to want each 
thread to have its own local copy of a variable. Most of the time, that 
should be precisely what you want anyway. So if you don't specifically 
tell the compiler you want the variable to be shared, then how is it, or 
the runtime, supposed to know that you didn't really intend for the 
variable to be thread-local?

Multithreaded programming is hard to reason about. If you aren't 
careful, shared variables can lead to race conditions and deadlocks. 
When variables are thread-local by default, you aren't going to run into 
these issues by accident. Adding that extra keyword is a reminder that 
you need to think carefully about what you are doing beforehand and 
actively opt-in to any potential variable sharing issues.