> Unfortunately I was unable to attend. I notice from the slides the > following statement: "Supports threading without a GIL (with some > caveats)"
> Just wondering what this caveats are? The only thing google suggests(*) > is https://forum.micropython.org/viewtopic.php?t=1864, which suggests > that Micropython may need a GIL in the future to fix some crash > conditions, but this post was from 2016. When running without a GIL access to individual Python objects is not protected from race conditions. So, for example, if one thread is mutating a list (adding an element) and another thread is also muting the same list (deleting elements) then this can lead to crashes. The way around this is to explicitly protect (using locks) objects which may be accessed by multiple threads at the same time. But if your code is sharing objects like this then probably it's a good idea to have locks in place. When using threading without a GIL just think of it like programming with threads in C: any communication between threads must be properly synchronised. The only things that are automatically protected from race conditions when the GIL is disabled is interning of strings and memory allocation (including garbage collection). Because these are things you can't really protect against using locks in Python code. Cheers, Damien.
_______________________________________________ melbourne-pug mailing list melbourne-pug@python.org https://mail.python.org/mailman/listinfo/melbourne-pug
