Skip to content

Instantly share code, notes, and snippets.

@ahmed-kamal2004

ahmed-kamal2004/gsoc.md

Last active November 14, 2025 17:29
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save ahmed-kamal2004/e22ea14969f064b92af0d1ad47ce02a1 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save ahmed-kamal2004/e22ea14969f064b92af0d1ad47ce02a1 to your computer and use it in GitHub Desktop.
Download ZIP
GSoC 2025
Raw
gsoc.md

Contributor

  • Contributor: Ahmed Kamal AbdElrasol

  • Location: Cairo, Egypt

  • Email: ahmedkamal200427@gmail.com

  • Mentors: Giovanni Grazioli, Florian Märkl

  • Project: Thread safety improvement

  • Organization: RizinOrg

Why is this project needed for Rizin ?

Rizin’s codebase has long relied too heavily on static and global variables. This design choice has become a major obstacle to making Rizin multi-threaded, limiting performance improvements and preventing smoother integration with Cutter.

The reliance on shared state prevents safe thread parallel execution, introduces race conditions, and forces heavy locking mechanisms that undermine scalability. As a result, Cutter cannot fully leverage Rizin as a responsive backend, which negatively impacts the overall user experience.

Eliminating global/static state and encapsulating functionality within well-defined contexts is a necessary step forward. Doing so would enable true multi-threading, improve responsiveness, and make Rizin far easier to extend, delivering a better, faster, and more seamless experience for Cutter users.

Problem explanation

Screenshot from 2025-08-29 18-24-55

All threads within a process share the same data segment, which is where global and static variables are stored. This means every thread sees and modifies the same global/static variables, which leads to race conditions and unsafe concurrent behavior.

In contrast, contexts work safely because they are allocated on the stack (per thread) or allocate separate heap memory for each thread and hand them their own copy. so each thread can hold its own instance of a context, meaning the data is private to that thread unless explicitly shared. This eliminates accidental interference, reduces the need for heavy locking, and makes the system safer without race conditions.

Project Goals

Here is a list containing most of the project goals:

  • RzUtil (path.c): Replace static variables with RzSys and RzPath context structures and remove constructor/destructor functions.
  • RzCore (agraph.c): Encapsulate static state into a non-exposed AGraphContext.
  • Update libmagic based on openbsd/src@0e59d0d : Update library and clean up any static variables.
  • RzIO Plugins (io_wingbg, io_self, io_qnx, io_plugin, io_gdb): Create a dedicated context per plugin to manage plugin-specific state.
  • RzAsm Plugins (cris, vax, lanai, arc, hppa, z80): Create a dedicated context per plugin to manage plugin-specific state.
  • RzBin Plugins (sms, avr, z64): Create a dedicated context per plugin to manage plugin-specific state.
  • WASM analysis: Remove static/global and replace with contexts.
  • RzLang: Remove static/global and replace with contexts.
  • RzEgg: Remove static/global and replace with contexts.
  • RzCons (cons.c, output.c): Carefully refactor static state into non-exposed structures while preserving Windows-specific behaviors “by testing on Windows environment”.
  • RzCore Terminal UI (TUI) (./librz/core/tui/): Encapsulate static state into a context to support multi-threaded TUI operation.
  • SDB: Remove unused static-variable-dependent functions, and refactor necessary ones to use context structures.

My Work

This project required a deep understanding of the Rizin codebase. To make precise and effective changes, I had to thoroughly study its architecture, including the core, utils, sdb, magic, and plugin subsystems (analysis, IO, ASM, bin, etc.).

Over the last three months, I submitted numerous PRs focused on removing static and global variables and replacing them with contexts and structs. This required significant refactoring to ensure the code functioned correctly with the new design. To validate these changes, We used extensive testing, including unit, integration, and regression tests, across multiple CI workflows on GitHub Actions, Travis CI, TinyCC, as well as local environments. Through this process, we confirmed that the refactor worked as expected, which also improved thread safety in the codebase.

Here is the list of my ( Merged / Open ) PRs that show my work during GSoC25.

Challenges

Working on this project came with several challenges that pushed me to grow both technically and personally:

  • Understanding a Large, Complex Codebase

    Rizin is a mature and extensive project. Gaining a deep understanding of how components like core, util, sdb, cmd, and plugins interact required significant time and effort.

  • Dealing with Static and Global Dependencies

    Static and global variables were deeply embedded across multiple layers of the codebase. Refactoring them without breaking functionality required extreme caution, careful analysis, and step-by-step changes to preserve functionality.

  • Maintaining Cross-Platform Compatibility

    Since Rizin supports Linux, macOS, FreeBSD, OpenBSD, QNX and Windows, every refactor had to be validated across many environments. Windows in particular presented unique challenges due to platform-specific behaviors and API differences.

  • Updating libmagic

    One of the most challenging tasks was updating libmagic. Rizin was relying on an outdated version of file implementation from OpenBSD (2009), which lacked modern improvements. Bringing it up to the 2015 implementation required carefully merging years of upstream changes while ensuring compatibility with Rizin’s existing codebase. This was not a straightforward replacement, I had to resolve API differences, adapt Rizin’s integration to the new structure, and verify that the behavior remained consistent across all supported platforms. The process demanded extensive testing and debugging, but in the end, it removed static dependencies, improved maintainability, and aligned Rizin with a more modern and secure upstream library.

Outcome

As a result of this project, the vast majority of the Rizin codebase is now thread safe. Only a few components remain, and the final decision on whether to refactor, remove, or keep them unchanged will be made by the mentors. Overall, this work brought Rizin to an important milestone, the codebase is now over 90% thread safe.

Future work

For future work, the remaining parts of the codebase should be discussed with the Rizin community to decide whether they should be removed, redesigned, or refactored. This collaboration will help push Rizin closer to becoming 100% thread-safe.

I truly appreciate the Rizin community, it is unique, supportive, and filled with talented people. I am proud to be part of it, and I plan to continue contributing to the Rizin codebase and infrastructure beyond GSoC. Many exciting changes in the Rizin ecosystem are expected in the near future, and I will do my best to be part of them.

Thank you all! 🙏

@sachinrathod11

sachinrathod11 commented Nov 14, 2025

Copy link
Copy Markdown

Hello maintainers,

My name is Sachin and I am interested in the GSoC project focusing on improving Rizin’s thread safety (removing global variables, refactoring RzUtil/RzCore/AGraph, etc.).

To get started, could you recommend:

  1. A beginner-friendly issue, or
  2. A small refactoring task
    that aligns with the goals of this project?

I would like to begin contributing and get familiar with the relevant parts of the codebase.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment