<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Actors on Abhishek Shukla</title><link>https://abhishekshukla.dev/tags/actors/</link><description>Recent content in Actors on Abhishek Shukla</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 02 Jul 2026 09:30:00 +0530</lastBuildDate><atom:link href="https://abhishekshukla.dev/tags/actors/index.xml" rel="self" type="application/rss+xml"/><item><title>Understanding Actor Reentrancy in Swift: The Hidden Concurrency Trap</title><link>https://abhishekshukla.dev/blog/swift-actor-reentrancy/</link><pubDate>Thu, 02 Jul 2026 09:30:00 +0530</pubDate><guid>https://abhishekshukla.dev/blog/swift-actor-reentrancy/</guid><description>&lt;p&gt;With the introduction of Swift Concurrency, &lt;strong&gt;Actors&lt;/strong&gt; became the ultimate tool for protecting shared mutable state. By isolating their state and ensuring that only one task can access that state at a time, actors eliminate traditional data races.&lt;/p&gt;
&lt;p&gt;However, they introduce a new, subtle, and incredibly dangerous concept that trips up even experienced developers: &lt;strong&gt;Actor Reentrancy&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;If you assume that an actor behaves exactly like a serial &lt;code&gt;DispatchQueue&lt;/code&gt; or an &lt;code&gt;NSLock&lt;/code&gt;, you are going to write buggy code. Let’s explore what actor reentrancy is, why it breaks your logic, and how to fix it using a real-world banking scenario.&lt;/p&gt;</description></item></channel></rss>