/ 
Linux-Event-0.010
River stage one • 4 direct dependents • 4 total dependents
/ Linux::Event::Loop

NAME

Linux::Event::Loop - Selector and public front door for Linux::Event engines

SYNOPSIS

use v5.36;
use Linux::Event::Loop;

my $reactor = Linux::Event::Loop->new(
  model   => 'reactor',
  backend => 'epoll',
);

my $proactor = Linux::Event::Loop->new(
  model   => 'proactor',
  backend => 'uring',
);

<<<<<<< HEAD ======= my $loop = Linux::Event->new( model => 'reactor', );

>>>>>>> 1401c31 (prep for cpan and release, new tool added) =head1 DESCRIPTION

Linux::Event::Loop is the stable public front door for this distribution. It does not implement the readiness engine or the completion engine itself. Instead, it selects one of the engine classes and delegates the public API to that implementation object.

The current engines are:

<<<<<<< HEAD This split keeps the public constructor short while allowing the reactor and proactor internals to evolve independently.

======= >>>>>>> 1401c31 (prep for cpan and release, new tool added) =head1 CONSTRUCTOR

new(%args)

Recognized selector arguments:

  • model

    Either reactor or proactor. This argument is required.

  • backend

    A backend name or backend object appropriate to the selected model.

Any remaining arguments are forwarded to the selected engine constructor.

COMMON METHODS

These methods are delegated for both models when supported:

  • backend_name

  • clock

  • is_running

  • run

  • run_once

  • stop

REACTOR METHODS

When the selected model is reactor, the following methods are available through the loop facade:

  • timer

  • backend

  • sched

  • signal

  • waker

  • pid

  • watch

  • unwatch

  • cancel

  • after

  • at

PROACTOR METHODS

When the selected model is proactor, the following methods are available through the loop facade:

  • read

  • write

  • recv

  • send

  • accept

  • connect

  • shutdown

  • close

  • after

  • at

  • live_op_count

  • drain_callbacks

If a method is not supported by the selected model, the loop croaks with a clear delegation error.

MODEL-SPECIFIC BEHAVIOR

This module does not try to erase the semantic difference between readiness and completion I/O. It only gives both engines a common entry point.

For readiness semantics, see Linux::Event::Reactor. For completion semantics, see Linux::Event::Proactor.

SEE ALSO

Linux::Event, Linux::Event::Reactor, Linux::Event::Proactor