AnyEvent-GDB

 view release on metacpan or  search on metacpan

GDB.pm  view on Meta::CPAN

=head1 NAME

AnyEvent::GDB - asynchronous GDB machine interface interface

=head1 SYNOPSIS

   use AnyEvent::GDB;

=head1 DESCRIPTION

This module is an L<AnyEvent> user, you need to make sure that you use and
run a supported event loop.

GDB.pm  view on Meta::CPAN

   my ($self, undef, $r) = @_;

   delete $_->{library}{$r->{id}}
      for $self->_thread_groups ($r);
}

=back

=head2 EVENTS

AnyEvent::GDB is asynchronous in nature, as the goal of the MI interface
is to be fully asynchronous. Due to this, a user of this interface must
be prepared to handle various events.

When an event is produced, the GDB object will look for the following four
handlers and, if found, will call each one in order with the GDB object
and event name (without C<on_>) as the first two arguments, followed by
any event-specific arguments:

=over 4

=item on_event method on the GDB object

README  view on Meta::CPAN

NAME
    AnyEvent::GDB - asynchronous GDB machine interface interface

SYNOPSIS
       use AnyEvent::GDB;

DESCRIPTION
    This module is an AnyEvent user, you need to make sure that you use and
    run a supported event loop.

    It implements the GDB MI protocol, which can be used to talk to GDB
    without having to parse the ever changing command syntax aimed at

README  view on Meta::CPAN

        This is purely a convenience method for small scripts: since it
        blocks execution using a condvar, it is not suitable to be used
        inside callbacks or modules.

        That is, unless Coro is used - with Coro, you can run multiple
        "cmd_sync" methods concurrently form multiple threads, with no
        issues.

  EVENTS
    AnyEvent::GDB is asynchronous in nature, as the goal of the MI interface
    is to be fully asynchronous. Due to this, a user of this interface must
    be prepared to handle various events.

    When an event is produced, the GDB object will look for the following
    four handlers and, if found, will call each one in order with the GDB
    object and event name (without "on_") as the first two arguments,
    followed by any event-specific arguments:

    on_event method on the GDB object
        Useful when subclassing.