<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Parallelism on Nalar</title>
    <link>https://nalar.dev/tags/parallelism/</link>
    <description>Recent content in Parallelism on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 08 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/parallelism/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Run CPU-Bound Python Work with InterpreterPoolExecutor</title>
      <link>https://nalar.dev/run-cpu-bound-work-with-interpreterpoolexecutor/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/run-cpu-bound-work-with-interpreterpoolexecutor/</guid>
      <description>&lt;p&gt;Python has traditionally offered two familiar high-level choices for parallel work: threads and processes. Python 3.14 adds a third option to &lt;code&gt;concurrent.futures&lt;/code&gt;: &lt;code&gt;InterpreterPoolExecutor&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;It runs workers in separate Python interpreters inside one process. Each worker has its own interpreter state and its own Global Interpreter Lock (GIL), so pure Python code can execute on multiple CPU cores at the same time.&lt;/p&gt;&#xA;&lt;p&gt;That makes the executor interesting for CPU-bound workloads, but it is not a drop-in way to make arbitrary threaded code parallel. Interpreter isolation changes the programming model. Mutable Python objects are not simply shared between workers, submitted work crosses a serialization boundary, imports and module globals are interpreter-local, and extension compatibility deserves deliberate testing.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
