> You should be able to run threaded applications unchanged by simply making
> sure that the "forks.pm" and "forks::shared.pm" modules are loaded, e.g. by
> specifying them on the command line.  This doesn't work still because the
> : shared attribute has not yet been implemented.

Liz,

Are you still working on forks::shared?  I'm very interested to see how your going to 
implement pseudo shared variables.

-J

On Mon, 28 Oct 2002, Elizabeth Mattijsen wrote:

> With pride I would like to announce "forks.pm" and associated modules:
>
> The uploaded file
>
>      forks-0.01.tar.gz
>
> has entered CPAN as
>
>    file: $CPAN/authors/id/E/EL/ELIZABETH/forks-0.01.tar.gz
>    size: 25850 bytes
>     md5: 725514c3f4f509d0705e4da0b95fe114
>
> ==============================================================================
> =head1 NAME
>
> forks - drop-in replacement for Perl threads using fork()
>
> =head1 SYNOPSIS
>
>    use forks;
>
>    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 -Mforks::shared threadapplication
>
> =head1 DESCRIPTION
>
> The "forks" pragma allows a developer to use threads without having to have
> a threaded perl, or to even run 5.8.0 or higher.  There were a number of goals
> that I am trying to reach with this implementation.
>
> =head2 memory usage
>
> The standard Perl 5.8.0 threads implementation is B<very> memory consuming,
> which makes it basically impossible to use in a production environment,
> particularly with mod_perl and Apache.  Because of the use of the standard
> Unix fork() capabilities, most operating systems will be able to use the
> Copy-On-Write (COW) memory sharing capabilities (whereas with the standard Perl
> 5.8.0 threads implementation, this is thwarted by the Perl interpreter
> cloning process that is used to create threads).  The memory savings have
> been confirmed.
>
> =head2 mod_perl / Apache
>
> This threads implementation allows you to use a standard, pre-forking Apache
> server and have the children act as threads (with the class method
> L<isthread>).  This is as yet untested within Apache, but should work.
>
> =head2 same API as threads
>
> You should be able to run threaded applications unchanged by simply making
> sure that the "forks.pm" and "forks::shared.pm" modules are loaded, e.g. by
> specifying them on the command line.  This doesn't work still because the
> : shared attribute has not yet been implemented.
>
> =head2 development / demonstration tool
>
> Because you do not need a threaded Perl to use forks.pm, you can start
> prototyping threaded applications with the Perl executable that you are used
> to.  Just download the "forks.pm" package from CPAN and install that.  So
> the threshold for trying out threads in Perl has become much lower.  Even
> Perl 5.005 should in principle be able to support the forks.pm module: because
> of some issues with regards to the availability of XS features between
> different versions of Perl, it seems that 5.8.0 (unthreaded) is what you need
> at least.
>
> =head1 IMPLEMENTATION
>
> This is the very first version that I'm making public.  There is still a lot
> to do, but the basic functionalities seem to work.  The missing pieces are
> just a matter of programming.  If you would like to participate in this,
> please do!
>
> This version is mostly written in Perl.  Inter-process communication
> is done by using sockets, with the process that stores the shared variables
> as the server and all the processes that function as threads, as clients.
>
> =head2 why sockets?
>
> The reason I chose sockets for inter-thread communication above using a shared
> memory library, is that a blocking socket allows you to elegantly solve the
> problem of a thread that is blocking for a certain event.  Any polling that
> might occur, is not occurring at the Perl level, but at the level of the
> socket, which should be much better and probably very optimized already.
>
> =head1 EXTRA CLASS METHODS
>
> Apart from the standard class methods, the following class methods are supplied
> by the "forks" threads implementation.
>
> =head2 isthread
>
>   unless (fork) {
>     threads->isthread; # this process is a detached thread now
>   }
>
> The "isthread" class method attempt to make a connection with the shared
> variables process.  If it succeeds, then the process will function as a
> detached thread and will allow all the threads methods to operate.
>
> This method is mainly intended to be used from within a child-init handler
> in a pre-forking Apache server.  All the children that handle requests become
> threads as far as Perl is concerned, allowing you to use shared variables
> between all of the Apache processes.
>
> =head2 debug
>
>   threads->debug( 1 );
>   $debug = threads->debug;
>
> The "debug" class method allows you to (re)set a flag which causes extensive
> debugging output of the communication between threads to be output to STDERR.
> The format is still subject to change and therefore still undocumented.
>
> =head1 CAVEATS
>
> Because of the use of sockets for inter-thread communication, there is an
> inherent larger latency with the interaction between threads.  However, the
> fact that sockets are used, may open up the possibility to share threads
> over more than one physical machine.
>
> =head1 KNOWN PROBLEMS
>
> These problems are known and will be fixed in the future:
>
> =over 2
>
> =item test-suite exits in a weird way
>
> Although there are no errors in the test-suite, the test harness thinks there
> is something wrong because of an unexpected exit() value.  Not sure what to do
> about this yet.
>
> =back
>
> =head1 CREDITS
>
> Lars Fenneberg for helping me through the initial birthing pains.
>
> Arthur Bergman for implementing the first working version of Perl threads
> support and providing us with an API to build on.
>
> ==============================================================================
> =head1 NAME
>
> forks::shared - drop-in replacement for Perl threads::shared with forks()
>
> =head1 SYNOPSIS
>
>    use forks;
>    use forks::shared;
>
>    my $variable : shared; # attributes do not work yet
>
>    share( $variable );
>    share( @array );
>    share( %hash );
>
>    lock( $variable );
>    cond_wait( $variable );
>    cond_signal( $variable );
>    cond_broadcast( $variable );
>
> =head1 DESCRIPTION
>
> The "forks::shared" pragma allows a developer to use shared variables with
> threads (implemented with the "forks" pragma) without having to have a
> threaded perl, or to even run 5.8.0 or higher.
>
> =head1 KNOWN PROBLEMS
>
> These problems are known and will be fixed in the future:
>
> =over 2
>
> =item :shared attribute
>
> The :shared attribute on variables does not work yet.  Use the
> L<threads::share> function instead.
>
> =item test-suite exits in a weird way
>
> Although there are no errors in the test-suite, the test harness thinks there
> is something wrong because of an unexpected exit() value.  Not sure what to do
> about this yet.
>
> =item shared variable in push() on shared array bombs
>
> For some reason, using a bare shared variable as a parameter in a push() on a
> shared array, bombs.  This can be fixed by adding B<.''> to the shared
> variable.
>
>    push( @shared,$shared );    # bombs
>    push( @shared,$shared.'' ); # works
>
> This could be a generic problem with tie() in Perl, judging from some very
> recent discussion on p5p.
>
> =back
>
> =head1 CREDITS
>
> Arthur Bergman for Hook::Scope (from which I swiped the code to have locked
> variables automatically unlock upon leaving the scope they were locked in) and
> threads::shared (from which I swiped the code to create references from the
> parameter list passed to a subroutine).
>
>
>
>

Reply via email to