The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

NAME

forks::BerkeleyDB - high-performance drop-in replacement for threads

VERSION

This documentation describes version 0.04.

SYNOPSYS

  use forks::BerkeleyDB;

  my $thread = threads->new( sub {       # or ->create or async()
    print "Hello world from a thread\n";
  } );

  $thread->join;

  threads->detach;
  $thread->detach;

  my $tid    = $thread->tid;
  my $owntid = threads->tid;

  my $self    = threads->self;
  my $threadx = threads->object( $tidx );

  threads->yield();

  $_->join foreach threads->list;

  unless (fork) {
    threads->isthread; # intended to be used in a child-init Apache handler
  }

  use forks qw(debug);
  threads->debug( 1 );

  perl -Mforks::BerkeleyDB -Mforks::BerkeleyDB::shared threadapplication

DESCRIPTION

forks::BerkeleyDB is a drop-in replacement for threads, written as an extension of forks. The goal of this module is to improve upon the core performance of forks at a level comparable to native ithreads.

REQUIRED MODULES

 BerkeleyDB (0.27)
 Devel::Required (0.07)
 forks (0.18)
 Storable (any)
 Tie::Restore (0.11)

USAGE

See forks for common usage information.

NOTES

Testing has been performed against BerkeleyDB 4.3.x. Full compatibility is expected with BDB 4.x and likely with 3.x as well. Unclear if all tie methods are compatible with 2.x. This module is currently not compatible with BDB 1.x.

CAVIATS

Environment and database files aren't currently purged after application exits. Files are unlinked if they ever collide with a new process' shared vars, and care has gone into insuring that no two running processes will ever collide, so it is not a critical issue. This will probably be resolved in the future by storing shared var thread usage in a separate database, and auto-purging when thus db refcount drops to 0 (in an END block to insure it cleanup occurs as frequently as possible.

This module defines CORE::GLOBAL::fork to insure BerkeleyDB resources are correctly managed before and after a fork occurs. This insures that processes will be able to safely use threads->isthread. You may encounter issues with your application or other modules it uses also define CORE::GLOBAL::fork. To work around this, you should modify your CORE::GLOBAL::fork to support chaining, like the following

        use subs 'fork';
        *_oldfork = \&CORE::GLOBAL::fork;
        sub fork {
                #your code here
                ...
                _oldfork->() if ref(*oldfork) eq 'SUB';
        }

TODO

Use shared process shutdown to purge BerkeleyDB database files.

Implement thread joined data using BerkeleyDB.

Determine what additional functions should be migrated to BerkeleyDB backend vs. those that should remain as part of the forks package.

Add a high security mode, where all BerkeleyDB data is encrypted using either native encryption (preferred, if available) or an external cryptography module of the user's choice (i.e. Crypt::* interface module, or something that supports a standard interface given an object instance).

AUTHOR

Eric Rybski <rybskej@yahoo.com>.

COPYRIGHT

Copyright (c) 2006 Eric Rybski <rybskej@yahoo.com>. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

SEE ALSO

forks, threads