Parrot_new should not need to be passed previously-created interps

[dukeleto]

Currently Parrot_new requires being passed in the 1st interp that was ever created to create subsequent interpreter objects.

In PL/Parrot, many interps must be created, some are trusted, some are not. But they all need to know about the 1st interp that was created, which, from a security standpoint, is suboptimal. Here is a snippet from PL/Parrot's plparrot.c :

    untrusted_interp = Parrot_new(NULL);

    /* Must use the first created interp as the parent of subsequently created interps */
    trusted_interp = Parrot_new(untrusted_interp);

[whiteknight]

This problem is caused by the current threading system. The threading system maintains a global array of created interpreter objects, and the first thread (the only one without a parent interp) is supposed to create that array. Creating a second interp without a parent enters into the same logic path, tries to fiddle with the global array in ways that aren't good, and we get errors.

The threading system is known to be broken in this and in other ways, and is currently undergoing a redesign. I will keep this ticket open as a reminder, but I am not certain if we are going to fix the bug as-is or if we are going to want to punt and avoid it in a hypothetical future system.

[whiteknight]

I think this issue is resolved following the kill_threads merge. Can anybody confirm?

[dukeleto]

I think this was fixed, but I will wait to confirm that a test exists for this before closing this ticket.