5 ms·
My understanding of the GIL is that its inclusion was justified by the fact that removing it would speed up multithreaded programs at the cost of slowing down s
by chimeracoder 14y ago
My understanding of the GIL is that its inclusion was justified by the fact that removing it would speed up multithreaded programs at the cost of slowing down single-threaded programs (the latter being more common than the former).
Given that, and given that the patches for removing the GIL were submitted for an earlier version a while back (2.4 or before, I believe), is it unfeasible/impossible to design an interpreter that detects whether a program requires support for multiple threads and then act accordingly? Since this currently requires the inclusion of a module, it seems like it would be unambiguous.
- sanxiyn 14y agoDetection will be non-trivial. On the other hand, it could be a simple command line option, like specifying the number of cores you want your program to run on.
- ori_b 14y agoI'm not sure about that. If you hook thread creation into invalidating the code that was was JITted without STM, you might be able to handle it reasonably well. Of course, the slow path would just use STM all the time.
- sanxiyn 14y ago> ... invalidating the code that was JITted ... I mean, that is non-trivial.
- ori_b 14y agoMaybe. If you determine that you only need to do it on spawning the first thread, and never go back, then you can probably spare the expense of throwing out ALL of the jit cache and starting from nothing.
- chimeracoder 14y agoNot really - we already have __future__ imports, which must be declared at the top of the file before any other modules. I think this could be achieved in a simple way in a similar fashion - some sort of a straightforward 'multithreaded' pragma shouldn't be too much of a burden.
- sanxiyn 14y ago__future__ is per-module, so while it is good for syntax changes, I think it is inappropriate for runtime pragmas.