On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger <[email protected]> wrote: > GC: > * Generational: > * requires barriers to handle bookkeeping at reference creation > * existing object attribute access barriers are: > (a) unwieldy and therefore not used consistently > (b) insufficient to support more complicated uses. a good > example is PMC aggregates.
I mentioned in #ps, but I don't think that this requires a deprecation. The write barriers already exist and are documented on their purpose and their uses. What we would be changing is the level of enforcement in their use, which doesn't really seem like a deprecation policy issue to me. We can add in a note if people want. > concurrency: > * not really sure where we are or what lies ahead here. anyone care > to forecast? All existing threading machinery should probably be listed as deprecated since the vast majority of it is going to need to be either completely ripped-out or radically modified in the months following 3.0. This includes the PMC types (Task, Timer, ParrotThread, whatever else I am forgetting) and the relevant opcodes as well. Also, and I need to look over some code first, I think the current callback mechanism needs to be either radically changed or completely killed and rewritten too. Some of this stuff may remain unchanged, but I think that is a minority subset if we are really dedicated to doing threading right. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
