InterpreterPoolExecutor é um executor do módulo concurrent.futures que permite executar tarefas em múltiplos interpretadores Python isolados dentro do mesmo processo. Ele combina uma interface parecida com ThreadPoolExecutor com paralelismo real para código Python, pois cada interpretador mantém seu próprio estado e seu próprio Global Interpreter Lock.
Neste guia, você vai entender como esse executor funciona, quando ele pode ser melhor do que threads ou processos, quais objetos podem ser enviados aos workers, como tratar inicialização, erros, isolamento e desempenho, além de boas práticas para aplicações reais.
Por que múltiplos interpretadores importam
Threads compartilham memória e são leves, mas tarefas intensivas em CPU escritas em Python normalmente disputam o mesmo GIL. Processos oferecem paralelismo verdadeiro, porém exigem processos separados, maior consumo de memória e comunicação entre espaços de memória independentes. Os interpretadores isolados ocupam uma posição intermediária: continuam dentro do mesmo processo do sistema operacional, mas cada worker possui um interpretador independente.
Esse isolamento significa que módulos, variáveis globais, caches e objetos mutáveis não são compartilhados automaticamente. A separação reduz vários tipos de condição de corrida, mas exige que o programador planeje explicitamente a comunicação.
Exemplo básico
from concurrent.futures import InterpreterPoolExecutor
def calcular(n):
return sum(i * i for i in range(n))
with InterpreterPoolExecutor(max_workers=4) as executor:
resultados = list(executor.map(calcular, [500_000] * 8))
print(resultados)
A interface segue o padrão dos executores de concurrent.futures. Você pode usar submit, map, futures, timeouts e tratamento de exceções de forma semelhante ao que já faria com threads ou processos.
Isolamento de estado
Cada interpretador possui seus próprios módulos importados, seu próprio sys.modules, variáveis globais e estruturas internas. Alterar um global em um worker não altera o mesmo global em outro. Objetos mutáveis comuns, como listas e dicionários, não podem ser simplesmente compartilhados por referência.
contador = 0
def tarefa():
global contador
contador += 1
return contador
Mesmo que várias tarefas chamem essa função, não conte com um único contador global compartilhado. O comportamento depende do interpretador que executa cada chamada. Para resultados previsíveis, envie dados como argumentos e devolva resultados explicitamente.
Serialização dos argumentos
As tarefas, argumentos e retornos precisam atravessar a fronteira entre interpretadores. Na prática, isso favorece funções definidas em módulos importáveis e dados simples ou serializáveis. Evite lambdas, closures complexas, objetos ligados a recursos locais e instâncias que dependam de estado não serializável.
from dataclasses import dataclass
@dataclass
class Trabalho:
inicio: int
fim: int
def processar(trabalho):
return sum(i ** 2 for i in range(trabalho.inicio, trabalho.fim))
Estruturas pequenas e imutáveis tornam a comunicação mais clara. Para volumes muito grandes, compare o custo de serialização com o tempo real de processamento.
Inicialização de workers
O executor pode inicializar cada interpretador com uma função própria. Isso é útil para importar bibliotecas, carregar configurações ou preparar recursos locais do worker.
def inicializar():
import math
global fator
fator = math.pi
def calcular_area(raio):
return fator * raio ** 2
with InterpreterPoolExecutor(
max_workers=4,
initializer=inicializar,
) as executor:
print(list(executor.map(calcular_area, [1, 2, 3])))
Cada worker executa a inicialização em seu próprio interpretador. Não use essa etapa para criar um objeto que você espera compartilhar globalmente com todos os workers.
Tratamento de exceções
Erros ocorridos nos workers são propagados por meio das futures. Sempre consuma os resultados e trate exceções, pois ignorar uma future pode esconder falhas relevantes.
from concurrent.futures import as_completed
with InterpreterPoolExecutor(max_workers=3) as executor:
futures = [executor.submit(calcular, n) for n in [10, -1, 100]]
for future in as_completed(futures):
try:
print(future.result())
except Exception as erro:
print(f"Falha: {erro}")
Uma falha de inicialização pode tornar o pool inutilizável. Registre a causa original e mantenha uma estratégia de fallback quando o serviço precisar continuar funcionando.
Quando usar
O executor é especialmente interessante para tarefas CPU-bound implementadas em Python puro, processamento independente de documentos, parsing, validação, transformação de dados, algoritmos combinatórios e workloads nos quais cada unidade de trabalho pode ser descrita por uma entrada pequena e um resultado pequeno.
Ele também pode ser útil quando você quer isolamento mais forte do que threads, mas prefere evitar alguns custos operacionais de múltiplos processos. Ainda assim, faça benchmark no ambiente real.
Quando não usar
Para operações predominantemente de rede, arquivos ou banco de dados, asyncio ou threads podem ser mais simples. Para bibliotecas nativas que já liberam o GIL, threads podem alcançar bom paralelismo com menor custo de comunicação. Para isolamento operacional completo, limites de memória independentes ou execução de código não confiável, processos separados continuam sendo mais apropriados.
Comparação com ThreadPoolExecutor
ThreadPoolExecutor compartilha todos os objetos do processo e tem comunicação barata, mas exige sincronização cuidadosa. InterpreterPoolExecutor reduz o compartilhamento implícito e permite paralelismo real de bytecode Python, ao custo de serialização, inicialização e maior consumo de memória por worker.
Leia também nossos guias sobre queue.SimpleQueue, os.process_cpu_count, asyncio.Runner e sys.monitoring.
Comparação com ProcessPoolExecutor
Ambos oferecem paralelismo para código Python e exigem comunicação explícita. Processos possuem isolamento do sistema operacional, podem sobreviver a certos tipos de falha de maneira diferente e permitem políticas independentes de recursos. Interpretadores evitam criar processos completos, mas continuam compartilhando o mesmo processo principal e suas limitações operacionais.
Dimensionamento do pool
Não escolha automaticamente dezenas de workers. Comece com a quantidade de CPUs realmente disponíveis ao processo e ajuste conforme consumo de memória, tempo das tarefas e custo de comunicação.
import os
workers = min(os.process_cpu_count() or 1, 8)
with InterpreterPoolExecutor(max_workers=workers) as executor:
...
Um limite conservador evita pressão excessiva de memória e ajuda a manter o serviço responsivo.
Tarefas maiores são melhores
Enviar milhares de tarefas minúsculas pode custar mais do que executar o trabalho localmente. Agrupe entradas em lotes para amortizar serialização, agendamento e retorno.
def processar_lote(valores):
return [calcular(v) for v in valores]
Meça tamanhos de lote diferentes. O ponto ideal depende da duração de cada cálculo e do volume de dados transferido.
Cancelamento e encerramento
Use context manager para garantir encerramento correto. Futures que ainda não começaram podem ser canceladas, mas uma tarefa em execução geralmente precisa terminar. Para serviços com prazos, combine timeouts, lotes menores e lógica cooperativa de interrupção.
Testes
Separe a função de negócio da infraestrutura de concorrência. Teste a função diretamente e crie testes adicionais para serialização, propagação de erros e execução no pool. Evite testes que dependam da ordem de conclusão das tarefas.
Observabilidade
Registre duração de fila, tempo de execução, tamanho do lote, número de workers, falhas e volume serializado. Métricas ajudam a identificar se o gargalo está no cálculo, na transferência ou na inicialização.
Compatibilidade
Antes de adotar o recurso, verifique a versão mínima suportada pelo seu projeto. Consulte a documentação oficial de concurrent.futures e as novidades do Python 3.14. Mantenha um fallback para ProcessPoolExecutor quando precisar executar em versões anteriores.
Fallback simples
try:
from concurrent.futures import InterpreterPoolExecutor as Executor
except ImportError:
from concurrent.futures import ProcessPoolExecutor as Executor
Esse padrão ajuda bibliotecas e aplicações que precisam funcionar em ambientes heterogêneos, embora o comportamento e o desempenho dos dois executores não sejam idênticos.
Boas práticas
Prefira funções de módulo, argumentos pequenos, retornos simples, pools dimensionados de forma conservadora, tarefas suficientemente grandes e tratamento explícito de exceções. Evite depender de globais, recursos não serializáveis e ordem de execução.
Conclusão
InterpreterPoolExecutor amplia as opções de paralelismo do Python. Ele é uma ferramenta promissora para código CPU-bound que se beneficia de interpretadores isolados e de uma API familiar. O ganho real depende do formato da tarefa, da quantidade de dados transferidos e das bibliotecas utilizadas. Faça benchmarks, mantenha fallback e trate o isolamento como parte central do design.
