Message204634
Oh, here is in interesting commit:
---
changeset: 33705:891042c94aed
branch: legacy-trunk
user: Tim Peters <tim.peters@gmail.com>
date: Sat Oct 09 22:33:09 2004 +0000
files: Python/thread.c
description:
Document the results of painful reverse-engineering of the "portable TLS"
code.
PyThread_set_key_value(): It's clear that this code assumes the passed-in
value isn't NULL, so document that it must not be, and assert that it
isn't. It remains unclear whether existing callers want the odd semantics
actually implemented by this function.
---
Here is a patch adding a _PyThread_set_key_value() function which behaves as I expected.
It looks like PyThread_set_key_value() got its strange behaviour from the find_key() of Python/thread.c.
Don't hesistate if you have a better suggestion for the name if the new function :-)
Another option is to modify directly the existing function, but it might break applications relying on the current (weird) behaviour. |
|
Date |
User |
Action |
Args |
2013-11-28 01:25:05 | vstinner | set | recipients:
+ vstinner, tim.peters, pitrou, Arfrever, neologix |
2013-11-28 01:25:04 | vstinner | set | messageid: <1385601904.88.0.0573958408814.issue19787@psf.upfronthosting.co.za> |
2013-11-28 01:25:04 | vstinner | link | issue19787 messages |
2013-11-28 01:25:03 | vstinner | create | |
|