%|Project|version|why|date|% &|SK1||http://libregraphicsworld.org/blog/entry/sk1-development-restarted%|%details%|%|2011|& &|SQLiteStudio|3|http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334%|%details%|%|2013|& ---- **Notes on the SQLiteStudio explanations** [DKF]: It seems that there were three issues: 1. The developer thinks we have the wrong attitude to threads. 2. The developer wants things that [Tk] doesn't provide. 3. The developer wants us to change the meaning of `$(…)` in [expr]essions. Of these, #2 is a mostly-legit complaint; [Tk] needs a lot of work. ***Threading model differences*** The issue with the threading model is that when you have state shared across threads, alterations to that state — including allocations of any value from storage — require locking that state so that you can make a change in a consistent fashion. Even worse, the releasing of values back into the memory pool requires deciding whether ''all'' threads are done with the value. That all requires locking (like the Python GIL) or a very complex garbage collector (like that used in Java or C#). ***Expression changes*** This is something that can be considered in 9.0, but changing it in between is against policy, especially as we ''[stooop%|%know]'' that it is already in use to mean other things. <>Development