Ticket #1880 (new todo)

Opened 11 years ago

Last modified 10 years ago

Parrot_new should not need to be passed previously-created interps

Reported by: dukeleto Owned by: dukeleto
Priority: normal Milestone:
Component: core Version: master
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: all

Description

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);

Change History

Changed 11 years ago by whiteknight

  • status changed from new to assigned
  • platform set to all
  • version changed from 2.10.0 to master
  • milestone 2.11 deleted

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.

Changed 11 years ago by jkeenan

  • component changed from none to core

Changed 10 years ago by whiteknight

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

Changed 10 years ago by dukeleto

  • owner changed from whiteknight to dukeleto
  • status changed from assigned to new
  • type changed from RFC to todo

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

Note: See TracTickets for help on using tickets.