aboutsummaryrefslogtreecommitdiffstats
path: root/sources/shiboken2/ApiExtractor/parser/codemodel.cpp
diff options
context:
space:
mode:
authorChristian Tismer <tismer@stackless.com>2020-03-05 18:22:09 +0100
committerChristian Tismer <tismer@stackless.com>2020-03-09 09:00:40 +0100
commita75527289b0d2bbb3a13d34e24fbce1be42601f9 (patch)
tree4f9d4ccad49cc4ec4a0f6d993c8e62446d8fc05c /sources/shiboken2/ApiExtractor/parser/codemodel.cpp
parent6baf94735ff683adb4233825a8b0adbd68e9ed8a (diff)
Avoid the GIL in SignalManager::retrieveMetaObject
After massive GIL savings in the generated code, there still exists a place where a lot of repeated GIL acquirements are done. It was observed that up to 24 consecutive calls to retrieveMetaObject(self) were made, all with the same value for 'self'. The code in question was: (1) Shiboken::GilState gil; (2) MetaObjectBuilder *builder = metaBuilderFromDict( \ reinterpret_cast<SbkObject *>(self)->ob_dict); (3) if (!builder) (4) builder = &(retrieveTypeUserData(self)->mo); (5) (6) return builder->update(); An exact analysis of the code showed that the GIL usage (1) could be moved out of the function into a deeper function that does updates in a branch (6). Function retrieveTypeUserData does not involve the Python interpreter at all (4). It took some time until it was proven that access to some special Python dictionary cannot reach the Python interpreter and therefore does not need the GIL as well (2). This replaces the abandoned effort to write a "Lazy GIL". It worked great for the example program, but had problems with some never finishing tests. After all, this solution is much simpler and works perfectly well. More effort seems not to be necessary to handle the GIL. Task-number: PYSIDE-803 Change-Id: I439009ff933fc6f498beb0c7f1523b6f985afda8 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Diffstat (limited to 'sources/shiboken2/ApiExtractor/parser/codemodel.cpp')
0 files changed, 0 insertions, 0 deletions