Hi Fijal, On 6 May 2015 at 23:15, Maciej Fijalkowski <fij...@gmail.com> wrote: > I was thinking, maybe instead we can add a feature to cffi "don't > release the GIL" and use that there? (it would be faster for example)
It would not work here: one problem is that gdbm_*() functions set the global variable gdbm_errno, which must be read afterwards in case of error. So even if the gdbm_*() function call is done without releasing the GIL, the GIL could still be released after the function call and before we check the global variable. In other words, "don't release the GIL around this C external call because I want it to be atomic" is really a hack. It would only work if we had "with atomic:" from STM, and then it's basically the same as what I've written, if "_lock == atomic". For performance we could imagine a hack where we support "with atomic" specially in the JIT, causing both the external function call to be done without releasing the GIL, and causing all other release-the-GIL-now to be ignored. This could be implemented relatively efficiently. Unsure it's worth the double trouble---for us and for the user of locks... A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
