> What about all situations where you want to use threads, but not due to resource constraints? I would assume your answer would be "don't use threads" but you

> What about all situations where you want to use threads, but not due to resource constraints? I would assume your answer would be "don't use threads" but you say you're not rabidly anti-thread. But you can use threads now,with the GIL? The discussion about removing the GIL is a performance issue? So - my answer would be "sure, if you want to use threads for convenience, go ahead - but note that in this case the GIL isn't a problem". > Of course, if the runtime knew it was only running one thread it could ignore much the synchronization code altogether, but we don't want to pay the tax of a single branch decision, do we? That's an interesting one. I'd love to see the numbers. Well, if you remove the GIL it would be a branch per elided lock. You may well also find yourself increasing the size of all potentially-shared data structures (to hold the lock). It would be interesting to compare that to the case of uncontended mutexes.