<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent posts by williamcorlin</title><link>https://forge.codesys.com/u/williamcorlin/</link><description>Recent posts by williamcorlin</description><language>en</language><lastBuildDate>Tue, 14 Jul 2026 11:55:31 -0000</lastBuildDate><atom:link href="https://forge.codesys.com/u/williamcorlin/profile/feed.rss" rel="self" type="application/rss+xml"></atom:link><item><title>The future and proper use of CAA.BOLT, CAA.SEMA,..</title><link>https://forge.codesys.com/forge/talk/Engineering/thread/e6c20a740e/?limit=25#85e8</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I've been moving in the same direction. For new libraries, I'm trying to minimize dependencies on APIs that look like they're being phased out unless the documentation explicitly recommends them.&lt;/p&gt;
&lt;p&gt;For synchronization primitives like CAA.BOLT and CAA.SEMA, I'd love to see an official replacement or abstraction layer that's guaranteed to remain stable across runtimes. That would make library development much cleaner than relying on platform-specific SysLib* implementations or conditional compilation everywhere.&lt;/p&gt;
&lt;p&gt;Until there's clearer guidance, my approach has been to isolate the locking mechanism behind a small wrapper interface. If CODESYS changes the recommended API in the future, only that wrapper needs to be updated instead of every library that uses it. It isn't perfect, but it's made maintenance much easier.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">williamcorlin</dc:creator><pubDate>Tue, 14 Jul 2026 11:55:31 -0000</pubDate><guid isPermaLink="false">https://forge.codesys.com3999ef2f57f74800b92b5047a0f77cbf585d6fc1</guid></item></channel></rss>