Changes between Version 1 and Version 2 of Ticket #28800, comment 5


Ignore:
Timestamp:
12/13/19 12:50:49 (2 years ago)
Author:
embray
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28800, comment 5

    v1 v2  
    1 An alternative approach (although one that would still be made easier with some internal refactoring of PARI) would be like Python's [https://docs.python.org/3.8/c-api/init.html#non-python-created-threads PyGILState_Ensure()].  This places some onus on users of PARI in multi-threaded code to make sure PARI's interpreter state is properly initialized before using it in a new thread, which is not an unfair thing to ask users to do.
     1An alternative approach (although one that would still be made easier with some internal refactoring of PARI*) would be like Python's [https://docs.python.org/3.8/c-api/init.html#non-python-created-threads PyGILState_Ensure()].  This places some onus on users of PARI in multi-threaded code to make sure PARI's interpreter state is properly initialized before using it in a new thread, which is not an unfair thing to ask users to do.
     2
     3
     4`*` I should clarify what I mean by this.  When multi-threading was added to PARI, a number of global variables were simply converted directly to thread-local variables (sometimes it's not clear to me if all of them need to be thread-local; I don't know).  By contrast, to use CPython again as an example (since I know it well), all variables that need to be thread specific (e.g. in PARI this would include things like the main stack pointer) are collected into a single [https://github.com/python/cpython/blob/82c83bd907409c287a5bd0d0f4598f2c0538f34d/Include/cpython/pystate.h#L51 PyThreadState] struct, which makes it much easier to manage.  Each thread has its own threadstate stored in a thread-local variable, so just one variable instead of a whole bunch (meaning only one call to the TSS APIs to get/set it). A similar reorganization of PARI's thread-specific variables would be helpful.