Async-Redis

 view release on metacpan or  search on metacpan

examples/slow-redis/README.md  view on Meta::CPAN

# Slow Redis Example

Demonstrates non-blocking I/O by intentionally delaying each request by 1 second.

## The Point

With **blocking I/O**, a single-threaded server handling 5 requests that each take 1 second would need 5 seconds total (sequential processing).

With **non-blocking I/O**, those same 5 concurrent requests complete in ~1 second because they all sleep concurrently while the event loop handles them.

## Running

```bash
# Start Redis
docker run -d -p 6379:6379 redis

# Start the server

examples/slow-redis/README.md  view on Meta::CPAN

```

## How It Works

1. Request arrives
2. `Future::IO->sleep(1)` yields control to the event loop
3. Event loop can accept and process other requests during the sleep
4. After 1 second, all sleeping requests wake up
5. Each request gets Redis TIME and responds

The key is that `Future::IO->sleep()` is **non-blocking** - it doesn't block the thread, it just schedules a callback for later while the event loop continues processing other work.

examples/slow-redis/app.pl  view on Meta::CPAN

    curl http://localhost:5001/fast

=head1 DESCRIPTION

This example demonstrates non-blocking I/O by intentionally sleeping for
1 second before returning a response. Despite the delay, the server can
handle many concurrent requests because the sleep is non-blocking.

With traditional blocking I/O:
- 5 sequential requests = 5 seconds
- 5 concurrent requests to a single-threaded server = 5 seconds

With non-blocking I/O (this example):
- 5 sequential requests = 5 seconds
- 5 concurrent requests = ~1 second (all sleep concurrently)

=head1 ENDPOINTS

=over 4

=item GET /

lib/Async/Redis/Subscription.pm  view on Meta::CPAN

prevents it. If you genuinely want to swallow errors, register an
explicit no-op: C<< $sub->on_error(sub { }) >>.

Callback exceptions (dying inside C<on_message>) are also routed to
C<on_error>; the callback-died message is prepended to the error
string.

=head2 Ordering guarantee

Callbacks fire in the order frames arrive on the connection. No
concurrent invocation (Perl is single-threaded and the driver runs on
the event loop). After a reconnect, C<on_reconnect> always fires before
any post-reconnect C<on_message>.

=head2 Re-entrancy

Inside an C<on_message> callback you may safely:

=over 4

=item * Call C<< $sub->subscribe(...) >> — the new channel is added

script/commands.json  view on Meta::CPAN

        ],
        "command_flags": [
            "readonly",
            "fast"
        ]
    },
    "UNLINK": {
        "summary": "Asynchronously deletes one or more keys.",
        "since": "4.0.0",
        "group": "generic",
        "complexity": "O(1) for each key removed regardless of its size. Then the command does O(N) work in a different thread in order to reclaim memory, where N is the number of allocations the deleted objects where composed of.",
        "acl_categories": [
            "@keyspace",
            "@write",
            "@fast"
        ],
        "arity": -2,
        "key_specs": [
            {
                "begin_search": {
                    "type": "index",