Author steve.dower
Recipients brett.cannon, eric.snow, grahamd, ncoghlan, serhiy.storchaka, steve.dower
Date 2016-12-29.17:47:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483033674.56.0.658040381148.issue29102@psf.upfronthosting.co.za>
In-reply-to
Content
That's an issue with TLS initialisation, not thread IDs. It's easily solved by defining an "uninitialized" value (e.g. 0) and an "invalid" value (e.g. -1).

Interpreter states are in a linked list, so you can traverse the list to find one by ID.

WRT weakrefs, we can't use them directly, but I suspect the higher-level API will need it. Possibly adding a callback on finalisation would fill both needs, but I like having a reliable ID - otherwise we'll probably end up with multiple different IDs managed indirectly via callbacks. (Perhaps a single callback for when any interpreter is finalized that passes the ID through? That should work well, since the ID is designed to outlive the interpreter itself, so it can be an asynchronous notification.)
History
Date User Action Args
2016-12-29 17:47:54steve.dowersetrecipients: + steve.dower, brett.cannon, ncoghlan, grahamd, eric.snow, serhiy.storchaka
2016-12-29 17:47:54steve.dowersetmessageid: <1483033674.56.0.658040381148.issue29102@psf.upfronthosting.co.za>
2016-12-29 17:47:54steve.dowerlinkissue29102 messages
2016-12-29 17:47:54steve.dowercreate