Názory k článku Nové vlastnosti Pythonu 3.14 v praxi: vliv odstranění GIL a využití více interpretrů

A jsou konecne ty nezavisle interpretery pouzitelne i pres C API tak, ze na sobe vubec nezavisi, ani skrz globalni stav?

Problem, ktery jsem dlouho resil, byla plugin-like architektura, kde runner je C++ executable, ktery jen nacita pluginy, krmi je daty a dava jim k dispozici vlakna, na kterych muzou bezet. A problem byl, kdyz jsem v pluginu chtel Python. Idealni reseni by bylo, aby o tom runner nic nevedel a kazdy plugin si sve potreby resil sam. Jenze to donedavna nebylo mozne, protoze nekdo musi Python inicializovat, a v plugin architekture se nevi, kdo... Leda ze by runner, ale to je dost nesystematicke (protoze v 90% budou pluginy C++ only).

21. 10. 2025, 08:32 editováno autorem komentáře

nekdo musi Python inicializovat, a v plugin architekture se nevi, kdo...

Vie. Prvý, kto ho potrebuje použiť. A niekde to poznačí, aby to ostatní našli. Takže to už iba použijú. Toto sa dá riešiť mnohými spôsobmi. Záleží iba na tom, či je to v rámci jedného procesu, jedného stroja, alebo na viacerých strojoch. A pokiaľ máte pod kontrolou ten exe súbor, tak je to možno ešte jednoduchšie. Môže mať API, ktoré tie pluginy môžu používať. Ale dá sa to aj bez toho, aby ste mali exe pod kontrolou. Ak by ten exe bol napríklad Apache alebo nginx a pluginy boli moduly zavádzané do nich.

Predpokladam, ze volani C kodu kdyz bude zakazany GIL, bude bez jakehokoli zamku? Tedy si to bude muset resit ten ceckovej kod sam, ze?

Je to popsané třeba zde: https://docs.python.org/3/howto/free-threading-extensions.html

Dik. Nakonec to asi nebude moc implementacne slozite.

Přiznám se, že moc nechápu, k čemu ty sub-interepretery jsou. Možnosti sdílení paměti podobně špatné jak u multiprocessingu, nároky na změnu C extensions pomalu větší než u no-GIL (například PyO3 sub-interpretery vůbec nepodporuje, ale no-GIL jo).

Na jaký use-case se to hodí?

Žere to míň paměti a komunikace mezi těmi vlákny je rychlejší než mezi procesy..