Who uses aiologic?

[x42005e1f]

There are three kinds of lies: lies, damned lies, and statistics. The same applies in our case: stars indicate how popular the idea might be (how successful the project's promotion is; even star-history.com recommends to inflate the star count!), downloads reflect the load on CI/CD (in particular, from major dependents) and forks generally do not tell us anything. We cannot even rely on feedback, since for high-quality tools… what is there to talk about anyway (if you put the tool under the hood and it does not bother you in any way, you will easily forget it even exists)? There are projects with hundreds of stars that are sometimes discussed in chat rooms but actually have zero usage, which just confirms how absurd these metrics are.

What if we want to measure the usefulness or usability of the project? We could analyze the dependents, but there is a problem: GitHub provides information on all dependents, including indirect ones (which are the vast majority; if A uses B, and B uses C, there is transitive "A uses C", but A itself knows nothing about C), and has false negatives and false positives. That is why this discussion exists.

Here, I will talk about direct dependents that I found on the Internet and how they use aiologic. I invite everyone who wants to join, especially those who use the project privately or on platforms where it is difficult to find any information (such as GitLab).

Last checked: 2026-08-07.

[x42005e1f]

x42005e1f/culsans (2024-11-02 – present; active)

This is my second project that provides an alternative to Janus queues. Initially, Culsans was created because of performance issues in the latter as a proof-of-concept, but over time it grew into an independent project. It relies on aiologic.Condition for its work, supports checkpoints, inherits the list of supported libraries, and has a lot more to offer.

The Culsans queues differ from the complex aiologic queues in the following aspects:

1. They have API-compatible interfaces.
2. They provide more features (such as dynamic maxsize adjustment).
3. They are capable of working safely with mixed (sync and async) calls in the same thread (the complex aiologic queues will deadlock in this case).

The price of these capabilities is that Culsans relies on a thread-level lock, which deviates from the aiologic concept.

[x42005e1f]

MatthewScholefield/meross-auto-lighting (2025-01-20 – present; inactive)

A script that controls Meross smart lights. It uses aiologic.lowlevel.AsyncEvent as a bridge between an asyncio Meross manager running in the main thread and a synchronous MQTT client running in another thread.

[x42005e1f]

Vizonex/aiothreading (2025-02-05 – present; active)

A fork of omnilib/aiomultiprocess that uses threads instead of processes. Once, I was looking at what solutions had been made before me and came across this project, which coincidentally was published in the same season as mine. It implemented its primitives, but via polling, which was used throughout the entire codebase, and I wanted to comment on a possible improvement. It all started with one issue and ended with the fact that aiothreading now actively relies on aiologic, and I am a collaborator there.

It uses various aiologic primitives to assemble asyncio threads and asyncio thread pools. Support for AnyIO is planned.

[x42005e1f]

logicblocks/event.store (2025-02-19 – present; active)

An eventing infrastructure with asyncio support that provides various storage adapters. It uses aiologic.Lock to synchronize an in-memory adapter between different threads and different event loops.

[x42005e1f]

DmitryBugaychenko/spade-llm (2025-04-01 – present; inactive)

A multi-agent system for LLM agents, running on asyncio. It uses aiologic.Event for synchronization between synchronous and asynchronous threads, and even implements its own asyncio threads for this purpose.

[x42005e1f]

apache/airflow (2025-04-07 – 2025-06-17)

A platform for managing workflows with asyncio support. It used aiologic.Lock to synchronize communication between threads and the supervisor (parent process). However, the asynchronous interface did not cover the entire architecture, resulting in deadlocks when mixing synchronous and asynchronous calls in the same thread (a fundamental problem that aiologic is unable to solve or detect in general). Later, communication was rewritten in pure asyncio (without aiologic.Lock), but mixed calls remained, which led to RuntimeError during such calls due to async_to_sync() from django/asgiref, and on a regular basis.

The original issue about deadlock with aiologic.Lock was opened on May 5, 2025. A new issue about a similar deadlock with asyncio.Lock+threading.Lock was opened on May 4, 2026, indicating that… they had entered a vicious cycle, and the problem had not actually been fixed (fun fact: this combination, as well as the related PRs^[1][2] suggesting to use threading.Lock via asyncio.to_thread()/loop.run_in_executor(), essentially mimics what aiologic.Lock was doing). It was finally fixed on May 5, 2026, exactly one year after the initial issue was opened, using one of the suggested options (replacing the lock with a separate worker).

This project is the reason why aiologic has a large number of "dependent" repositories and a large number of downloads in the past. That is why aiologic was in the top 2,000 most-downloaded packages from PyPI.

[x42005e1f]

academy-agents/academy (2025-06-25/2025-07-05 – present; active)

A multi-agent system with asyncio support, built on the actor model. It uses aiologic.Lock to synchronize access to local message queues in different threads with different event loops.

[x42005e1f]

Vizonex/aiointernal (2025-08-06 – present; inactive)

A worker thread implementation with an asyncio interface, which delegates the execution of selected methods. It uses aiologic.REvent for synchronization on close state.

[x42005e1f]

AetherBreaker/LegendLoreBot (2025-08-11 – present; inactive)

A Discord bot written using disnake with a modular architecture, running on asyncio. It uses aiologic.Lock to synchronize access to the database cache synchronously and asynchronously.

[x42005e1f]

AetherBreaker/ScheduledOrderMiddleman (2025-10-01 – present; active)

A scheduler that executes commands via SFTP (actually, it is something more niche, but I did not go into details), running on asyncio. It uses aiologic.Lock to synchronize access to the database cache synchronously and asynchronously.

[x42005e1f]

fleming79/async-kernel (2025-11-04 – present; active)

An implementation of a Python Jupyter kernel with concurrent request handling, running on AnyIO. It uses various aiologic primitives to synchronize asynchronous code with synchronous threads.

This project was the reason for the early release of aiologic 0.15.0 (as it was the first project I found that works on something other than asyncio).

[x42005e1f]

microsoft/agent-lightning (2025-12-05 – present; inactive)

An optimizing trainer for AI agents. It uses aiologic.Lock to implement thread-safe collections with an asyncio interface, and further migration is planned.

[x42005e1f]

datarobot-community/talk-to-my-data-agent (2025-12-08 – present; active)

A question answering (QA) system over structured data, running on asyncio. It uses aiologic.Lock to ensure exclusive write access to a DuckDB storage.

[x42005e1f]

klaw-python/klaw (2025-12-17 – present; inactive)

klaw-result is a collection of various types inspired by Rust, with support for AnyIO. It uses aiologic.Event and aiologic.Lock to implement mixed primitives.

[x42005e1f]

orangeqs/juice (2025-11-21 – present; active)

A platform for managing and automating quantum device testing. It uses aiologic.SimpleQueue to send messages to a websockets server running on asyncio in a separate thread (for testing purposes).

[x42005e1f]

AmritaBot/AmritaCore (2026-04-12 – present; active)

An agent framework, built on asyncio. It uses aiologic.Lock mostly as a replacement for threading.Lock to avoid blocking the event loop when synchronizing a sequence of non-async operations (no await under the context manager yields to the event loop) between asynchronous tasks in different threads… in theory. In reality, though, it seems it never parallelizes asynchronous code.

[JohnRichard4096]

Thanks for the analysis. Honestly, we moved to aiologic for two reasons: 1) deadlock detection (lifesaver), and 2) prepping for multi‑agent parallelism down the road. So yeah, it’s not parallel yet—that’s phase two. Sorry for the confusion

[x42005e1f]

Good to know. Thank you for the details.

At the time, I suspected that might be the reason, but the existence of anyio.Lock (with the same deadlock detection; it has hard-coded checkpoints, but you can pass fast_acquire=True) as an alternative seemed to me to be the factor that might indicate otherwise.

[JohnRichard4096]

Good to know. Thank you for the details.

At the time, I suspected that might be the reason, but the existence of anyio.Lock (with the same deadlock detection; it has hard-coded checkpoints, but you can pass fast_acquire=True) as an alternative seemed to me to be the factor that might indicate otherwise.

Yeah, we looked at anyio.Lock. Deadlock detection is nice, but the main driver is our in-planned multi‑agent feature: we need to synchronize state containers need be accessed both synchronously and asynchronously. aiologic.Lock's mixed locking does that with minimal glue code.

[x42005e1f]

AmritaBot/AmritaBot (2026-04-26 – present; active)

A chatbot platform based on AmritaBot/AmritaCore. It uses aiologic.Lock as a direct replacement for asyncio.Lock (see above for why).

[x42005e1f]

AetherBreaker/sft_ext (2026-05-21 – present; active)

A shared library containing all the primitives whose usage was described in relation to the same author's projects (see above).

[x42005e1f]

AmritaBot/AmritaSense (2026-05-17 – present; active)

An interpretive workflow engine, running on asyncio. It encapsulates some classes previously found in AmritaCore, such as MatcherFactory (which uses aiologic.Lock for category-based synchronization) and SuspendObjectStream (which uses aiologic.Lock to ensure exclusive access on callbacks) and also uses aiologic.Lock in the same manner as the latter to synchronize interpreter steps.

[x42005e1f]

AmritaBot/plugin-memory (2026-05-02 – present; active)

…

[x42005e1f]

eeeob/aldheeb-pytools (2026-06-02 – 2026-07-30)

…

[x42005e1f]

WePositive-energy/wepositive-di (2026-06-03 – present; active)

…

[x42005e1f]

Vizonex/anyio-executor (2026-06-10 – present; active)

…

[x42005e1f]

LiteSuggarDEV/nonebot_plugin_amrita (2026-06-21 – present; active)

…

[x42005e1f]

AetherBreaker/shared-log-processor (2026-07-01 – present; unavailable)

…

[x42005e1f]

iyad-f/sonyflake (2026-07-07 – present; active)

…

[x42005e1f]

Attacking-Lab/ctf-attackapi (2026-02-07 – present; active)

…

[x42005e1f]

AmritaBot/mcp-ssh-reloaded (2026-07-13 – present; active)

…

[x42005e1f]

redsun-acquisition/redsun (2026-07-26 – present; active)

…

[x42005e1f]

AmritaBot/Faskill (2026-08-03 – present; active)

…