> Для чего нужен GIL?Он нужен для конкурентной многозадачности без сложного кода атомарного доступа к одним и тем же объектам из разных потоков. Это нужно, чтобы банальное присвоение любого объекта не прерывалось на середине. Я не знаю, когда был введён GIL, но судя по патчу для Python 1.4, который его удаляет, в 1996 году он уже стал частью Питона.
Глобальный блокировщик -- идея очень простая, и введена как раз поэтому. Да, она не позволяет работать на множестве ядер, но будем честными, в 1996 году об этом точно никто не задумывался. Я не знаю, когда именно был введён GIL, но первые x86 двухядерные процы появились сильно позже, да и многопроцессорные системы были достаточно редкими, чтобы о них париться.
В ядре линукса было что-то похожее, Big Kernel Lock
> Почему нельзя без GIL обойтись?
Можно. Если есть деньги на развитие и поддержку проекта, то вполне можно заменить мегалок на много атомарных. В Джаве нет. В Шарпе нет. В Linux нет с 2011 года (заметим, спустя шесть лет с выхода многоядерного x86).
Но это сложно, однозначно приведёт огромному количеству сложноуловимых багов и на первых порах сильно просадит однопоток. А на последних сделает добавление новых фич очень затратным делом.
Теперь ответ на вопрос, а какие есть альтернативы в Питоне: многопроцесность. Да, как в хроме, можно запустить питонов по количеству ядер и организовать проброс сообщений между ними через очереди (Queue). В большинстве случаев этого хватает. Тот же flask так делает. Часто сложный, долгий код выносят в C(++), где можно наплодить потоков как душе угодно, если они не меняют в разных потоках переменные питоновского кода.
Кстати, GIL -- это то самое "лучше чем ничего". Года три назад, в PHP многопоток был небезопасен, в JavaScript его не было вовсе, в Lua каком-нибудь и до сих пор нет. В нативных языках типа C(++) или Fortran атомарное присвоение не гарантируется, там проще. В Rust подрублен серьёзный статический анализ. Не знаю, как там в остальных языках.
