view release on metacpan or  search on metacpan

README  view on Meta::CPAN

STARTING THE SERVER
    Typically you will want to start the client and server as completely
    separate processes as shown in the synopses.

    Running the server and the client in the same process is technically
    possible but is highly discouraged since the server will "fork()" when
    the client demands a new worker process. In this case, all descriptors
    in use by the client are duped into the worker process and the worker
    ought to close these extra descriptors. Also, forking a busy client may
    be memory-inefficient (and dangerous if it uses threads).

    Since it's more of a bother than it's worth to run the server and the
    client in the same process, there is an alternate server constructor,
    "AnyEvent::Task::Server::fork_task_server" for when you'd like to fork a
    dedicated server process. It can be passed the same arguments as the
    regular "new" constructor:

        ## my ($keepalive_pipe, $server_pid) =
        AnyEvent::Task::Server::fork_task_server(
          name => 'hello',

README  view on Meta::CPAN

    that even when the server is shutdown, existing worker processes and
    checkouts may still be active in the client. The client object and all
    checkout objects should be destroyed if you wish to ensure all workers
    are shutdown.

    Since the "fork_task_server" constructor calls fork and requires using
    AnyEvent in both the parent and child processes, it is important that
    you not install any AnyEvent watchers before calling it. The usual
    caveats about forking AnyEvent processes apply (see the AnyEvent docs).

    You should also not call "fork_task_server" after having started threads
    since, again, this function calls fork. Forking a threaded process is
    dangerous because the threads might have userspace data-structures in
    inconsistent states at the time of the fork.

INTERFACE
    When creating a server, there are two possible formats for the
    "interface" option. The first and most general is a coderef. This
    coderef will be passed the list of arguments that were sent when the
    checkout was called in the client process (without the trailing callback
    of course).

    As described above, you can use a checkout object as a coderef or as an

lib/AnyEvent/Task.pm  view on Meta::CPAN

The C<min_workers> argument determines how many "hot-standby" workers should be pre-forked when creating the client. The default is 2 though note that this may change to 0 in the future.





=head1 STARTING THE SERVER

Typically you will want to start the client and server as completely separate processes as shown in the synopses.

Running the server and the client in the same process is technically possible but is highly discouraged since the server will C<fork()> when the client demands a new worker process. In this case, all descriptors in use by the client are duped into th...

Since it's more of a bother than it's worth to run the server and the client in the same process, there is an alternate server constructor, C<AnyEvent::Task::Server::fork_task_server> for when you'd like to fork a dedicated server process. It can be ...

    ## my ($keepalive_pipe, $server_pid) =
    AnyEvent::Task::Server::fork_task_server(
      name => 'hello',
      listen => ['unix/', '/tmp/anyevent-task.socket'],
      interface => sub {
                         return "Hello from PID $$";
                       },
    );

The only differences between this and the regular constructor is that C<fork_task_server> will fork a process which becomes the server and will also install a "keep-alive" pipe between the server and the client. This keep-alive pipe will be used by t...

If C<AnyEvent::Task::Server::fork_task_server> is called in a void context then the reference to this keep-alive pipe is pushed onto C<@AnyEvent::Task::Server::children_sockets>. Otherwise, the keep-alive pipe and the server's PID are returned. Closi...

Since the C<fork_task_server> constructor calls fork and requires using AnyEvent in both the parent and child processes, it is important that you not install any AnyEvent watchers before calling it. The usual caveats about forking AnyEvent processes ...

You should also not call C<fork_task_server> after having started threads since, again, this function calls fork. Forking a threaded process is dangerous because the threads might have userspace data-structures in inconsistent states at the time of t...





=head1 INTERFACE

When creating a server, there are two possible formats for the C<interface> option. The first and most general is a coderef. This coderef will be passed the list of arguments that were sent when the checkout was called in the client process (without ...

As described above, you can use a checkout object as a coderef or as an object with methods. If the checkout is invoked as an object, the method name is prepended to the arguments passed to C<interface>: