Forking vs read_color_table()

[melak]

Consider the following:

use GD::Simple;

for (1..100)
{
    my $pid = fork;

    if(!defined($pid))
    {
        next;
    }

    if($pid == 0)
    {
        GD::Simple->new->bgcolor('transparent');
        exit;
    }
}

This fails more often than not, producing the following output:

unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856, <DATA> line 52.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856, <DATA> line 55.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856.
[...]

With some debugging put in, it becomes reasonably clear that DATA's position is literally all over the place, reading completely random stuff from completely random places in Simple.pm. The gist of this obviously comes down to DATA being a typeglob and all that, in a concurrent scenario like the above, several processes read from it, some will be missing some data, eventually one of them will also make it skip past __END__, and after a short while everything goes bonkers.

I've been playing with a couple of naive ideas for a fix, but the only real solution seems to be not building %COLORS at run-time.

Any other suggestions or observations perhaps before I put in a pull request with a static table?

[rurban]

No, sounds good