Skip Menu |

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 78097
Status: open
Priority: 0/
Queue: Math-BigInt

Owner: Nobody in particular
Requestors: BBYRD [...]

Bug Information
Severity: Important
Broken in: 1.997
Fixed in: (no value)

Subject: Global variables aren't thread safe
The following variables should be migrated to the OO interface: $round_mode $accuracy $precision $upgrade $downgrade Or rather, the OO interface should keep local copies of these variables. As it stands right now, changes via $obj->option($val) will change the global variables directly. That breaks thread safety and the overall expectations of an OO interface. It should work like this: * A call to new, copy, or any of the number creation methods should also create a local copy of the global variables in the blessed object, if $self doesn't already exist. * A call to one of the methods above or 'config' should: if (exists $self->{var}) { return|set $self->{var}; } elsif (blessed $self) { create a local copy then return|set; } else { return|set $global; } * All internal calls that use these variables should use $self->option and never the globals directly. This will ensure that calls to '$obj->option' or '$obj->config' use the local variables, and calls to 'Math::BigInt->option' or 'Math::BigInt->config' directly change the global options.
Download (untitled) / with headers
text/plain 356b
Currently, the accuracy and precision are stored in each instance, but for the other three variables (round_mode, upgrade, and downgrade), wouldn't it be sufficient to have a file-private lexical variable (e.g., my %config) to hold these variables? I have only recently started reading about thread safety, so pardon my lack of knowledge on these matters.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to