On 09/08/2017 12:30 PM, Benjamin Peterson wrote: > > On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote: >> >> On 09/08/2017 12:04 PM, Benjamin Peterson wrote: >>> - Why not run all (Python) finalizers on the thread and not just ones >>> from cycles? >> Two reasons: >> >> 1. Because some code relies on the finalizer being called on the thread >> where the last reference is dropped. This is usually the same >> thread where the object was created. Some irritating third-party >> libraries make demands on callers, e.g. "you can only interact with >> / destroy X objects on your 'main thread'". This is often true of >> windowing / GUI libraries. (For example, I believe this was true of >> Direct3D, at least as of D3D8; it was also often true of Win32 USER >> objects.) > Is the requirement that the construction and destruction be literally on > the same thread or merely non-concurrent? The GIL would provide the > latter. Literally the same thread. My theory was that these clowntown external libraries are hiding important details in thread local storage, but I don't actually know. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170908/2abdb9c6/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4