=head1 NAME

XS::Framework::Manual::SVAPI::threads - XS::Framework THREADED Perl support

=head1 THREADED Perl support

C<XS::Framework> strictly sets C<PERL_NO_GET_CONTEXT> option so that you need to have C<my_perl> (C<aTHX>) in scope.
This way threaded perl works faster.

C<XS::Framework> concept is all about sharing C code, modules
that use L<XS::Framework> cannot have different C<PERL_NO_GET_CONTEXT> state.
Because in either case, binary incompability between function signatures would occur.

To help dealing with threaded perls C<XS::Framework> defines my_perl alias at global scope, so you could get rid of annoing C<pTHX> and C<aTHX> in
every C function.

This alias resolves to appropriate perl interpreter pointer in such a way that it costs almost nothing until you create second thread.
This is in contrast to perl's default C<dTHX> or C<PERL_GET_THX> which are relatively expensive at C-speeds. After second thread is created, the
alias reverts to C<PERL_GET_THX> speeds.

Keep in mind that threaded perl will definitely be slower than standart perl even if you don't create threads because of penalties in perl source code
itself. Penalties are usually 20-50% so i would not recommend using threaded perl unless you *really* need perl threads.

Keep in mind that if you call functions with C<pTHX> in theirs signature or call perl functions (not macros, for example Perl_* functions) you still
need to pass C<aTHX> manually. However the speedups covered above still apply to C<aTHX>.

=head1 SEE ALSO

L<XS::Framework>

L<XS::Framework::Manual::SVAPI>

=cut
