DEV Community: Aria Diniz

Stack Frames and Function Calls: How They Create CPU Overhead

Aria Diniz — Fri, 24 Jan 2025 16:54:12 +0000

I love almost every topic in Computer Science and Software Engineering, but the part I probably love the most is Low-Level Programming. It's fascinating to study, experiment, and understand what happens at the edge between software and hardware. Sometimes, this knowledge helps you debug and solve problems, even in high-level application programming. One example is the Stack Memory. Understanding how it works—especially when working close to the hardware—is crucial to avoiding and debugging problems.

In this article, I’ll discuss how frequent function calls in a program can create overhead and degrade performance. This content assumes you already have some knowledge about stack and heap memory, as well as CPU registers, to follow the explanation.

What is a Stack Frame?

Imagine you just executed a program on your computer. Your operating system calls the scheduler, which reserves memory for your program and gets it ready for the CPU to process its instructions. This reserved memory is where your program allocates stack memory. In most systems, the default maximum stack size per thread is 8 MB.

If you’re using a Linux or Unix system, you can check this value with the following command:

ulimit -s

The stack memory is used to save the parameters passed to your program, allocate memory for local variables, and store the program’s execution context. One of the main differences between stack memory and heap memory is that the stack is much faster. Since the memory for the stack is reserved by the OS at the start of execution, you don’t need to call the OS every time you allocate something. Instead, your code simply updates the memory address pointed to by the top of the stack and continues execution. This makes the stack ideal for small, short-lived data like local variables, while larger or longer-lived data is allocated in the heap via system calls to the OS.

During program execution, many functions may be called. For example, imagine the following code snippet:

#include <stdio.h>

int sum(int a, int b) {
  return a + b;
}

int main() {
  int a = 1, b = 3;
  int result;

  result = sum(a, b);
  printf("%d\n", result);
  return 0;
}

When you call the sum function, the CPU must switch the execution context from the main function to sum. To do this, the CPU spends cycles preparing to execute the new instructions. Specifically, it must:

Save the current values of CPU registers in the stack memory.
Save the memory address of the next instruction (to resume main after sum returns).
Change the Program Counter (PC) to point to the first instruction of sum.
Store the function arguments (depending on the calling convention, this might involve placing them in registers or the stack).

This collection of saved data is called a Stack Frame. Each time a function is called, a new stack frame is created, and when the function finishes, the reverse process occurs, restoring the previous execution context.

Impact on Performance

As described earlier, calling and returning from functions introduces CPU overhead. This becomes more noticeable in scenarios like loops with frequent function calls or deep recursion, where managing the stack frames becomes a significant portion of the workload.

For critical performance scenarios, such as embedded software or game development, C provides tools to minimize this overhead. For instance, you can use macros or the inline keyword to reduce function call overhead. Here’s an example:

static inline int sum(int a, int b) {
  return a + b;
}

Alternatively, you can use a macro:

#define SUM(a, b) ((a) + (b))

While both options avoid the overhead of creating stack frames, inline functions are preferred because they provide type safety, unlike macros, which can introduce subtle bugs (e.g., multiple evaluations of arguments).

It’s important to note that modern compilers are highly optimized and often perform function inlining automatically, especially with optimization flags like -O2 or -O3. Explicit use of inline or macros is usually unnecessary unless you’re working in specific contexts like embedded systems, where every cycle counts.

Practical Insights

To illustrate what happens under the hood, you can examine the assembly generated by a simple function call to the sum function provided at the start of this article. Using objdump or gdb, you can see how the CPU manages registers and the stack:

0000000000001149 <sum>:
    1149:       f3 0f 1e fa             endbr64                # Indirect branch protection (may vary by system)
    114d:       55                      push   %rbp            # Save base pointer
    114e:       48 89 e5                mov    %rsp,%rbp       # Set new base pointer
    1151:       89 7d fc                mov    %edi,-0x4(%rbp) # Save first argument (a) on the stack
    1154:       89 75 f8                mov    %esi,-0x8(%rbp) # Save second argument (b) on the stack
    1157:       8b 55 fc                mov    -0x4(%rbp),%edx # Load first argument (a) from the stack
    115a:       8b 45 f8                mov    -0x8(%rbp),%eax # Load second argument (b) from the stack
    115d:       01 d0                   add    %edx,%eax       # Add the two arguments
    115f:       5d                      pop    %rbp            # Restore base pointer
    1160:       c3                      ret                    # Return to the caller

Here, you see instructions for setting up and tearing down the stack frame (push, mov, pop) and the actual computation (add). Each function call adds a similar sequence, contributing to overhead.

When Optimization Matters

CPUs today are capable of performing trillions of operations per second, and in most cases, the performance impact of function calls is negligible. However, in some fields—like embedded systems or computationally intensive applications—these optimizations can be critical. Embedded processors, for instance, often have limited performance and memory, making stack management more expensive. Similarly, optimizing function calls can reduce latency in real-time systems or speed up mathematical computations in resource-intensive simulations.

That said, this article isn’t advocating for sacrificing code readability for performance. Instead, it aims to shed light on what happens under the hood when a program runs.

Understanding and Solving False Sharing in Multi-threaded Applications with an actual issue I had

Aria Diniz — Sun, 01 Dec 2024 20:39:00 +0000

Recently, I was working on a multi-threaded implementation of a function to calculate the Poisson distribution (amath_pdist). The goal was to divide the workload across multiple threads to improve performance, especially for large arrays. However, instead of achieving the expected speedup, I noticed a significant slowdown as the size of the array increased.

After some investigation, I discovered the culprit: false sharing. In this post, I’ll explain what false sharing is, show the original code causing the problem, and share the fixes that led to a substantial performance improvement.

The Problem: False Sharing in Multi-threaded Code

False sharing happens when multiple threads work on different parts of a shared array, but their data resides in the same cache line. Cache lines are the smallest unit of data transferred between memory and the CPU cache (typically 64 bytes). If one thread writes to part of a cache line, it invalidates the line for other threads—even if they’re working on logically independent data. This unnecessary invalidation leads to significant performance degradation due to repeated reloading of cache lines.

Here’s a simplified version of my original code:

void *calculate_pdist_segment(void *data) {
    struct pdist_segment *segment = (struct pdist_segment *)data;
    size_t interval_a = segment->interval_a, interval_b = segment->interval_b;
    double lambda = segment->lambda;
    int *d = segment->data;

    for (size_t i = interval_a; i < interval_b; i++) {
        segment->pdist[i] = pow(lambda, d[i]) * exp(-lambda) / tgamma(d[i] + 1);
    }
    return NULL;
}

double *amath_pdist(int *data, double lambda, size_t n_elements, size_t n_threads) {
    double *pdist = malloc(sizeof(double) * n_elements);
    pthread_t threads[n_threads];
    struct pdist_segment segments[n_threads];
    size_t step = n_elements / n_threads;

    for (size_t i = 0; i < n_threads; i++) {
        segments[i].data = data;
        segments[i].lambda = lambda;
        segments[i].pdist = pdist;
        segments[i].interval_a = step * i;
        segments[i].interval_b = (i == n_threads - 1) ? n_elements : (step * (i + 1));
        pthread_create(&threads[i], NULL, calculate_pdist_segment, &segments[i]);
    }

    for (size_t i = 0; i < n_threads; i++) {
        pthread_join(threads[i], NULL);
    }

    return pdist;
}

Where the Problem Occurs

In the above code:

The array pdist is shared among all threads.
Each thread writes to a specific range of indices (interval_a to interval_b).
At segment boundaries, adjacent indices may reside in the same cache line. For example, if pdist[249999] and pdist[250000] share a cache line, Thread 1 (working on pdist[249999]) and Thread 2 (working on pdist[250000]) invalidate each other’s cache lines.

This issue scaled poorly with larger arrays. While the boundary issue might seem small, the sheer number of iterations magnified the cost of cache invalidations, leading to seconds of unnecessary overhead.

The Solution: Align Memory to Cache Line Boundaries

To fix the problem, I used posix_memalign to ensure that the pdist array was aligned to 64-byte boundaries. This guarantees that threads operate on completely independent cache lines, eliminating false sharing.

Here’s the updated code:

double *amath_pdist(int *data, double lambda, size_t n_elements, size_t n_threads) {
    double *pdist;
    if (posix_memalign((void **)&pdist, 64, sizeof(double) * n_elements) != 0) {
        perror("Failed to allocate aligned memory");
        return NULL;
    }

    pthread_t threads[n_threads];
    struct pdist_segment segments[n_threads];
    size_t step = n_elements / n_threads;

    for (size_t i = 0; i < n_threads; i++) {
        segments[i].data = data;
        segments[i].lambda = lambda;
        segments[i].pdist = pdist;
        segments[i].interval_a = step * i;
        segments[i].interval_b = (i == n_threads - 1) ? n_elements : (step * (i + 1));
        pthread_create(&threads[i], NULL, calculate_pdist_segment, &segments[i]);
    }

    for (size_t i = 0; i < n_threads; i++) {
        pthread_join(threads[i], NULL);
    }

    return pdist;
}

Why Does This Work?

Aligned Memory:
- Using posix_memalign, the array starts on a cache line boundary.
- Each thread’s assigned range aligns neatly with cache lines, preventing overlap.
No Cache Line Sharing:
- Threads operate on distinct cache lines, eliminating invalidations caused by false sharing.
Improved Cache Efficiency:
- Sequential memory access patterns align well with CPU prefetchers, further boosting performance.

Results and Takeaways

After applying the fix, the runtime of the amath_pdist function dropped significantly. For a dataset I was testing, the wall clock time dropped from 10.92 seconds to 0.06 seconds.

Key Lessons:

False sharing is a subtle yet critical issue in multi-threaded applications. Even small overlaps at segment boundaries can degrade performance.
Memory alignment using posix_memalign is a simple and effective way to solve false sharing. Aligning memory to cache line boundaries ensures threads operate independently.
Always analyze your code for cache-related issues when working with large arrays or parallel processing. Tools like perf or valgrind can help pinpoint bottlenecks.

Thank you for reading!

For anyone curious about the code, you can find it here

Advanced Math Library for C

Aria Diniz — Sun, 20 Oct 2024 22:12:05 +0000

Hello There!

In this post I will share a C library I created: Advanced Math Library, or libamath. This is a C library that centralizes some of my mathematical implementations, focusing on performance and multithreading.

libamath includes algorithms such as Kendall Correlation, Genetic Algorithms for optimization, Fourier Transforms, and various statistical calculations like mean, median, and standard deviation. I'm also planning to add support for BigInt factorial, which will offer higher precision for Poisson Distribution and other advanced calculations. Many of these functions are optimized with multithread support to handle intensive computational tasks.

Here are some examples of how you can use libamath:

Kendall Correlation:

double data1[] = {1.0, 2.0, 3.0};
double data2[] = {3.0, 2.0, 1.0};
double tau = amath_kcorr(data1, data2, 3);
printf("Kendall's Tau: %f\n", tau);

Genetic Algorithm:

void *fitness_function(Individuals *individuals) {
  // Define fitness logic
  return NULL;
}
Individuals *pop = amath_generate_individuals(100, 0.05, 0.001, 0.25, 4, 0.0, 1.0);
for (int i = 0; i < 1000; i++) {
  amath_fit(pop, fitness_function);
  amath_mutate(pop);
  amath_reproduce(pop);
}
amath_destroy_individuals(pop);

Discrete Fourier Transform (DFT):

double complex data[] = {1.0, 2.0, 3.0, 4.0};
amath_dft(data, 4, 2); // Perform DFT using 2 threads

Mean:

double data[] = {1.0, 2.0, 3.0};
double mean_value = amath_mean(data, 3);
printf("Mean: %f\n", mean_value);

For those familiar with my previous repositories, libamath brings together both the Kendall Correlation (now with performance improvements) and the Genetic Algorithm implementations into one place. This will make it easier to expand and manage the tools over time.

In my free time, I intend to add even more features, including:

Variance Calculation: Handy alongside the standard deviation.
Covariance: To measure how two datasets vary together.
Linear Regression: To model relationships between variables.
Binomial Distribution: A great complement to the Poisson distribution.
Gamma Distribution: Another versatile probability distribution.

This is something I built some time ago, since I often use these functions in my work, and I decided to share it in case anyone else finds it useful.

You can check out the project and contribute here: https://github.com/ariasdiniz/advanced_math_lib

As always, suggestions and feedback are very welcome!

C Project Starter: A Command-Line Tool for New C Projects

Aria Diniz — Mon, 12 Feb 2024 12:35:49 +0000

In the past few months, I've been dedicating a lot of time to one of my goals for this year: mastering the C language. As a result of this goal, I have been developing several projects in the language, from implementing data structures to tools to help me in my daily tasks. Since I've been incorporating this language into my routine quite a bit, I've created a tool to assist in creating new projects, aiming to save time writing boilerplate, setting up folder structures, etc. I named the project C Project Starter, and it's available on my GitHub.

C Project Starter was created to be used as a command-line tool on UNIX systems. To install it, simply clone the repository and run the install.sh script. You can also choose manual installation. Instructions are available in the project's README.md.

Using the tool is very simple. After installing it, just run

cgen –name project_name -c 23

in the terminal, where "project_name" is the name of your project, and "23" is the desired C version. The tool will create a directory with the project name containing gitignore, main.c, and CMakeLists.txt files, and it will also have subdirectories src, lib, and include.

If there is a need, either mine or from a user, I will improve the tool by adding more customization options.

If you like the project or have any suggestions for changes or criticisms, feel free to get in touch, comment here, or open an issue on the project.

Thank you for reading this far!

Building a Thread-Based Web Server without using any third-party libraries or frameworks with Ruby

Aria Diniz — Sat, 03 Jun 2023 00:03:59 +0000

Hi There!

Today, I'd like to showcase something I've been working on: a web server built entirely from scratch using Ruby. The goal isn't to present the project per se, but rather to share some insights and knowledge I've gained through this journey. I'll be explaining the architecture, its pros and cons, and an overall view of how it works.

This server is part of MacawFramework, an open-source Ruby framework designed to help developers create web applications with ease.

Server Architecture

The server is built around Ruby's TCPServer class and incorporates a thread-based architecture. The ThreadServer class includes a base module, ServerBase, which is primarily responsible for handling the HTTP protocol. Together, these components provide a default implementation for our web server.

The code demonstrates usage of key Ruby features, such as the Queue class for thread-safe data handling and the Mutex class for synchronization. It also takes advantage of Ruby's OpenSSL library to integrate SSL security into the server.

class ThreadServer
  include ServerBase

  def run
    @server = TCPServer.new(@bind, @port)
    @server = OpenSSL::SSL::SSLServer.new(@server, @context) if @context
    ...
  end
  ...
end

Thread-based Model

The thread-based model is simple yet effective. Upon starting the server, it spins up a specified number of worker threads that handle client connections. Incoming connections are queued in a work queue (@work_queue), where they are then processed by the worker threads, ensuring fair scheduling and load distribution.

def run
  ...
  @num_threads.times do
    spawn_worker
  end
  ...
end

private

def spawn_worker
  @workers_mutex.synchronize do
    @workers << Thread.new do
      loop do
        client = @work_queue.pop
        break if client == :shutdown

        handle_client(client)
      end
    end
  end
end

Thread Pool Management

The server uses a Mutex (@workers_mutex) to safely manage the worker threads pool. A maintenance routine runs in a separate thread, checking the health of the worker threads every 10 seconds. It will respawn any threads that have died, ensuring consistent server performance.

def run
  ...
  Thread.new do
    loop do
      sleep 10
      maintain_worker_pool
    end
  end
  ...
end

private

def maintain_worker_pool
  @workers_mutex.synchronize do
    @workers.each_with_index do |worker, index|
      unless worker.alive?
        if @is_shutting_down
          @macaw_log&.info("Worker thread #{index} finished, not respawning due to server shutdown.")
        else
          @macaw_log&.error("Worker thread #{index} died, respawning...")
          @workers[index] = spawn_worker
        end
      end
    end
  end
end

Graceful Shutdown

The server is designed to gracefully shut down when required, making sure all pending connections in the work queue are processed before closing the worker threads and the server itself.

def close
  shutdown
end

private

def shutdown
  @is_shutting_down = true
  ...
  @workers.each(&:join)
  @server.close
end

Limitations

While the threading model is effective, it has some limitations due to Ruby's Global Interpreter Lock (GIL). The number of concurrent connections it can handle is limited by the number of worker threads. Additionally, slow clients could potentially tie up a worker thread, reducing the server's capacity. However, for JRuby and TruffleRuby users, this threading model can leverage true system-level threading due to the lack of a GIL, potentially providing better performance on multi-core systems.

Despite these trade-offs, the built-in web server in MacawFramework offers a good balance for most web applications, particularly for small to medium scale deployments. For larger-scale applications with high concurrency demands, consider supplementing the built-in server with an event-driven architecture or utilizing a third-party server solution better suited for such scenarios.

Conclusion

In summary, the thread-based web server included in MacawFramework provides a straightforward, efficient, and secure solution for running your web applications, requiring minimal configuration and making deployment a breeze. It's a demonstration of how core Ruby features can be leveraged to build a simple yet robust web server.

I hope this journey through the creation of a thread-based web server was insightful. There's always more to learn and improve, so let's keep sharing and growing. Happy coding!

Building an Event Booking App in Ruby with Macaw Framework: A Step-by-Step Guide

Aria Diniz — Mon, 15 May 2023 23:19:51 +0000

Hi There!

Today, I'm excited to walk you through building an Event Booking app using the Macaw Framework. This tutorial is perfect for beginners looking to learn the basics of web development with Ruby in a simple way. The full code of this example can be found here.

Project Overview

Our Event Booking app has the following features:

User sign-up and login
Event creation
Booking of events

We're using SQLite for our database, and ActiveRecord as our ORM.

Step 1: Setting up the project

Create a new directory for your project and initialize a new Gemfile by running bundle init. Make sure to include the following gems:

gem 'macaw_framework'
gem 'active_record'
gem 'sqlite3'
gem 'yaml'
gem 'json'

Then, install your gems with bundle install.

Step 2: Setting up the database

Next, we'll set up our SQLite database. For this project, we'll use an example SQLite database that's included in the repository:

db_config = File.open('../db/database.yaml')
ActiveRecord::Base.establish_connection(YAML.safe_load(db_config, aliases: true))

Step 3: Defining the Routes

We define routes for each of our features. We'll create separate modules for each set of related routes. For instance, here's how we define our routes for booking:

def self.set_booking_routes(macaw)
  book_event(macaw)
  get_all_bookings(macaw)
end

In the book_event function, we define a POST route at '/bookings'. This route expects the client to send a JSON body with the name of the event to book. We'll parse this JSON, perform some validation, and then call our BookingsHandler to book the ticket:

def self.book_event(macaw)
  macaw.post('/bookings') do |context|
    name = JSON.parse(context[:body])
    raise 'You must log in to book a concert' if context[:client].nil? || context[:client][:login].nil?
    raise 'The "name" of the event cannot be null.' if name.nil?

    BookingsHandler.book_ticket(context[:client], name['name'])
    return JSON.pretty_generate({ message: 'Event booked with success' }), 200, { 'Content-Type': 'application.json' }
  rescue StandardError => e
    return JSON.pretty_generate({ message: e.message }), 400, { 'Content-Type': 'application.json' }
  end
end

Step 4: Implementing the Handlers

Each handler module is responsible for specific functionalities. For instance, the ClientsHandler module handles user sign-up and login.

Here's how we implement the signup process. We ensure that the request body contains a username and password, and then we hash the password before storing it in the database. If the client already exists, we raise an error:

def self.signup(macaw)
  macaw.post('/signup') do |context|
    body = JSON.parse(context[:body])
    raise 'The request body must have username and password fields' if body.nil?
    raise 'The request body must have a username field' if body['username'].nil?
    raise 'The request body must have a password field' if body['password'].nil?

    ClientsHandler.signup(body)
    return JSON.pretty_generate({ message: 'Client registered' }), 201, { 'Content-Type': 'application/json' }
  rescue StandardError => e
    return JSON.pretty_generate({ message: e.message }), 400, { 'Content-Type': 'application/json' }
  end
end

Step 5: Managing Sessions

Managing user sessions is a crucial part of any application. In our case, we're using the session[:client] to store our session data. For example, during the login process, we set session[:client] to the username of the logged-in user:

def self.login(body, session)
  pswd = body['password']
  user = Clients.find_by(username: body['username'])
  raise 'User not found' if user.nil?
  raise 'Incorrect Password!' unless Digest::SHA2.hexdigest(pswd) == user.password

  session[:login] = user.username

Conclusion

This is just a glimpse of how you can use Ruby with Macaw Framework to build an Event Booking app. There are many more features you can add, and I hope this guide gives you a good starting point. If you want to see the full application code, you can check out the GitHub repository.

Remember, the Macaw Framework is designed for simplicity and performance. It allows you to easily configure your web application with just a few lines of code, without the necessity of learning a Domain Specific Language (DSL).

Happy coding!

Simplifying Backend APIs with Macaw Framework: A CRUD Tutorial

Aria Diniz — Fri, 05 May 2023 12:16:08 +0000

If you're tired of configuring a lot of parameters and things you wouldn't even use when creating simple backend APIs, you might want to check out Macaw Framework. In my previous post, I introduced Macaw Framework, a lightweight and flexible web framework. Now, I'd like to show you how to use Macaw Framework to build a simple CRUD application.

It's worth noting that, despite being production ready, Macaw Framework is still in its first beta version. I encourage you to try it out, give feedback, and report any issues you encounter. Your feedback will be invaluable in helping me to improve the framework and make it even better for the community.

In this article, I'll guide you through the steps to build a simple CRUD application using Macaw Framework. You can find the code for this application on GitHub here. If you're not familiar with Macaw Framework, I encourage you to read my previous post on the topic to get a better understanding of how the framework works.

Macaw Framework is designed to be simple and easy to use, with sensible defaults that make it easy to get started. It's also highly customizable, with a wide range of options for configuring your application to meet your needs. Whether you're building a simple API or a complex web application, Macaw Framework can help you get the job done quickly and efficiently.

Step 0: Create and Configure Your `application.json` File

Before we dive into building our CRUD application, we need to create and configure our application.json file. This file will contain configuration options for our Macaw Framework application.

Create a new file called application.json in the root directory of your project and add the following contents:

{
  "macaw": {
    "threads": 10,
    "bind": "0.0.0.0",
    "port": 8080,
    "cache": {
      "cache_invalidation": 10,
      "ignore_headers": [
        "Postman-Token"
      ]
    },
    "prometheus": {
      "endpoint": "/metrics"
    },
    "rate_limiting": {
      "window": 10,
      "max_requests": 10
    }
  }
}

This file contains various options that will be used by Macaw Framework to configure your application. For example, the threads option specifies the number of threads that should be used by the application, while the cache option configures caching behavior. You can adjust these options to suit the needs of your application.

Once you've created your application.json file, you're ready to start building your CRUD application using Macaw Framework!

Step 1: Set Up Your Environment

To get started, create a new directory for your project and navigate into it. Then, add a Gemfile with the following content:

# frozen_string_literal: true

source "https://rubygems.org"

gem "sqlite3"

gem "yaml"

gem "json"

gem "macaw_framework"

gem "activerecord"

For this demo project I'm using a SQLite3 database. You can find the database and everything else in the project's repository.

Next, run bundler in order to install the dependencies:

bundle install

Using Bundler makes it easier to manage dependencies for your project, and ensures that all team members are using the same versions of the required gems. Once you have your dependencies installed, you're ready to start building your application with Macaw Framework!

Step 2: Define Your Person Model

Create a new file called person.rb in a subdirectory called lib/entity. This file will define your Person model, which represents a person in your database.

class Person < ActiveRecord::Base
  table_name = 'people'
end

Step 3: Create Your App File

Create a new file called app.rb in the root directory of your project. This file will be the entry point for your application, and it will define your Macaw Framework endpoints.

# frozen_string_literal: true

require 'macaw_framework'
require 'active_record'
require 'yaml'
require_relative './lib/entity/person'
require_relative './lib/errors/unprocessable_body_error'

# Configuring ActiveRecord
db_config = File.open('./db/database.yaml')
ActiveRecord::Base.establish_connection(YAML.safe_load(db_config, aliases: true))

# Instantiating MacawFramework Class
server = MacawFramework::Macaw.new

Step 4: Define Your GET Endpoint

The first endpoint we'll define will allow us to retrieve a list of all people in the database. Add the following code to your app.rb file:

# Defining a GET endpoint to list all persons in the database
server.get('/people', cache: true) do |_context|
  return JSON.pretty_generate(Person.all.as_json), 200, {"Content-Type" => "application/json", "random-header" => "random value"}
end

Step 5: Define Your GET by Id Endpoint

The second endpoint we'll define will allow us to retrieve a specific person from the database by their ID. Add the following code to your app.rb file:

# Defining a GET endpoint to recover person with provided id
server.get('/people/:person_id') do |context|
  return JSON.pretty_generate(Person.where(id: context[:params][:person_id]).first.as_json), 200
end

Step 6: Define Your POST Endpoint

The third endpoint we'll define will allow us to create a new person in the database. Add the following code to your app.rb file:

server.post('/add_new_person') do |context|
  begin
    parsed_body = JSON.parse(context[:body])
    name = parsed_body['name']
    age = parsed_body['age']
    raise UnprocessableBodyError if name.nil? || age.nil?

    Person.create!(name: name, age: age)
    return JSON.pretty_generate({ message: "Person created with success!!!" }), 201
  rescue UnprocessableBodyError => e
    return JSON.pretty_generate({ error: e }), 422
  rescue StandardError => e
    return JSON.pretty_generate({ error: e }), 500
  end
end

This endpoint will create a new Person record in the database based on the provided request body, which should be a JSON object with name and age properties. If the request body is missing either property, we'll raise our custom UnprocessableBodyError and return a 422 Unprocessable Entity status code with an error message.

Note that we're also raising a new custom error class, UnprocessableBodyError, if the request body is missing the required properties. To define this error class, create a new file called unprocessable_body_error.rb in your lib/errors directory with the following contents:

class UnprocessableBodyError < StandardError
  def initialize(
    msg = 'Please inform a body on your request in JSON format with a "name" and "age" properties'
  )
    super
  end
end

This error will be rescued in our PATCH and POST endpoint and return a 400 Bad Request status code with an error message if the request body is missing the required properties.

Step 7: Define Your PATCH Endpoint

The fourth endpoint we'll define will allow us to update an existing person in the database. Add the following code to your app.rb file:

server.patch('/people/:person_id') do |context|
  raise UnprocessableBodyError.new unless context[:params][:person_id]

  body = JSON.parse(context[:body])
  name = ActiveRecord::Base.connection.quote(body["name"])
  age = ActiveRecord::Base.connection.quote(body["age"])
  Person.update(
    context[:params][:person_id].to_i,
    name: name,
    age: age
  )
  [JSON.pretty_generate({ message: "Updated person #{context[:params][:person_id]}" }), 200]
rescue UnprocessableBodyError
  ["Person with id #{context[:params][:person_id]} does not exist", 400]
rescue StandardError => e
  [JSON.pretty_generate(e.message), 500]
end

Step 8: Define Your DELETE Endpoint

The fifth and final endpoint we'll define will allow us to delete an existing person from the database. Add the following code to your app.rb file:

# Defining a DELETE endpoint to delete an existing person in the database
server.delete('/delete_person') do |context|
  begin
    parsed_body = JSON.parse(context[:body])
    id = parsed_body['id']
    raise UnprocessableBodyError.new('Please inform a JSON body with an "id" parameter') if id.nil?

    person = Person.find_by(id: id.to_i)
    if person.nil?
      return JSON.pretty_generate({ error: "Person with ID #{id} not found." }), 404
    else
      person.destroy
      return JSON.pretty_generate("Person with ID #{id} deleted."), 200
    end
  rescue UnprocessableBodyError => e
    return JSON.pretty_generate({ error: e.message }), 422
  rescue StandardError => e
    return JSON.pretty_generate({ error: e }), 500
  end
end

Step 9: Start Your Server

Finally, add the following code to your app.rb file to start the server:

# Start Server
server.start!

Now that you've defined all of your endpoints, you're ready to start your server and test your application! You can do this by running the following command:

ruby app.rb

Your server will start running on http://localhost:8080/. You can use tools like Postman or cURL to send requests to your endpoints and test your application.

Now that we've defined all of our endpoints, we're ready to start our server and test our application!

Introducing the Macaw Framework: A Simple, Evolving Ruby Web Framework

Aria Diniz — Sun, 30 Apr 2023 19:49:06 +0000

Hello there! I am excited to introduce you to the Macaw Framework, a Ruby-based web framework that I have been passionately developing. The focus of Macaw is on simplicity and ease-of-use, while still providing powerful features. In this post, I will showcase the framework's core features and guide you through building a basic web application using Macaw. Let's get started!

Setting up Macaw

To begin, install the Macaw gem and create a new file named app.rb. In this file, require the Macaw Framework and create an instance of the Macaw class:

require "macaw_framework"

app = MacawFramework::Macaw.new

Creating HTTP Endpoints with Ease

Macaw offers straightforward methods for creating HTTP endpoints, such as get, post, put, patch, and delete. Each method accepts a path and a block of code that's executed when a request is made to the path. For example, to create a GET endpoint at the path /hello:

app.get("/hello") do |context|
  "Hello, world!"
end

Rate Limiting: Simple and Effective

Enabling rate limiting is easy. Just update your application.json configuration file with the desired rate limiting settings:

{
  "macaw": {
    ...
    "rate_limiting": {
      "window": 60,
      "max_requests": 100
    },
    ...
  }
}

With this configuration, clients will be limited to a maximum of 100 requests per minute.

SSL Support: Secure Your Application

To enable SSL, add the following to your application.json:

{
  "macaw": {
    ...
    "ssl": {
      "cert_file_name": "path/to/your/cert.pem",
      "key_file_name": "path/to/your/key.pem"
    },
    ...
  }
}

Ensure you replace the file paths with the actual paths to your SSL certificate and private key files.

Caching: Improve Performance

To enable caching for a specific endpoint, set the cache parameter to true when creating the endpoint:

app.get("/cached_hello", cache: true) do |context|
  "Hello, world! (cached)"
end

Cache also needs some configuration on the application.json file:

{
  "macaw": {
    ...
    "cache": {
      "cache_invalidation": 3600
    },
    ...
  }
}

Monitoring with Prometheus: Stay Informed

To enable Prometheus monitoring, add the following to your application.json:

{
  "macaw": {
    ...
    "prometheus": {
      "endpoint": "/metrics"
    },
    ...
  }
}

This will enable Prometheus monitoring for your application.

Starting the Server: Ready, Set, Go!

To start the Macaw server, simply call the start! method:

app.start!

This will start the server on the configured host and port.

In summary, the Macaw Framework provides a simple and flexible API for building web applications in Ruby. I am proud of the progress made so far; nevertheless, there is always room for growth and improvement. Check out the Macaw Framework's GitHub repository here and dive into the code! I invite you to join me on this journey and contribute to the Macaw Framework's development, so if you have some time to test and experiment with it, give me your feedback!

DEV Community: Aria Diniz

Stack Frames and Function Calls: How They Create CPU Overhead

What is a Stack Frame?

Impact on Performance

Practical Insights

When Optimization Matters

Understanding and Solving False Sharing in Multi-threaded Applications with an actual issue I had

The Problem: False Sharing in Multi-threaded Code

Where the Problem Occurs

The Solution: Align Memory to Cache Line Boundaries

Why Does This Work?

Results and Takeaways

Key Lessons:

Advanced Math Library for C

C Project Starter: A Command-Line Tool for New C Projects

Building a Thread-Based Web Server without using any third-party libraries or frameworks with Ruby

Server Architecture

Thread-based Model

Thread Pool Management

Graceful Shutdown

Limitations

Conclusion

Building an Event Booking App in Ruby with Macaw Framework: A Step-by-Step Guide

Project Overview

Step 1: Setting up the project

Step 2: Setting up the database

Step 3: Defining the Routes

Step 4: Implementing the Handlers

Step 5: Managing Sessions

Conclusion

Simplifying Backend APIs with Macaw Framework: A CRUD Tutorial

Step 0: Create and Configure Your application.json File

Step 1: Set Up Your Environment

Step 2: Define Your Person Model

Step 3: Create Your App File

Step 4: Define Your GET Endpoint

Step 5: Define Your GET by Id Endpoint

Step 6: Define Your POST Endpoint

Step 7: Define Your PATCH Endpoint

Step 8: Define Your DELETE Endpoint

Step 9: Start Your Server

Introducing the Macaw Framework: A Simple, Evolving Ruby Web Framework

Setting up Macaw

Creating HTTP Endpoints with Ease

Rate Limiting: Simple and Effective

SSL Support: Secure Your Application

Caching: Improve Performance

Monitoring with Prometheus: Stay Informed

Starting the Server: Ready, Set, Go!

Step 0: Create and Configure Your `application.json` File