Deprecate Threads

Vasily Chekalkin bacek at
Mon Jan 3 05:37:29 UTC 2011


Can we at least start with designing new APIs before ripping out old
system? Then we can compre effort of migrating vs ripping.


On Sun, Jan 2, 2011 at 2:10 PM, Christoph Otto <christoph at> wrote:
> On 12/31/2010 10:50 AM, Andrew Whitworth wrote:
>> On Fri, Dec 31, 2010 at 12:05 PM, chromatic<chromatic at>  wrote:
>>> I agree with the rationale for replacing the existing threading system,
>>> but is
>>> it really so unrecoverable that we can't use our traditional mechanism of
>>> replacement?
>>> 1) design a better API
>>> 2) hide the current malfeasances behind said API
>>> 3) replace the backend in place
>> I do understand your point, and I thought about suggesting something
>> like that instead. However, considering the amount of (known-working)
>> code in src/thread.c compared to the interfaces and logic we would
>> need to update to make an API that we wanted for the future and the
>> amount of work it would take to transform the current system to fit
>> the new API, it really doesn't make a lot of sense.
> If we have a use case where threads allow a user to do some kind of useful
> work, we should preserve that.  Replacing an interface while maintaining the
> old one is harder than ripping it out and reimplementing it from the ground
> up.  It's very much worthwhile if the old interface is in some way usable,
> but I don't think that's the case here.  If someone can come up with a use
> case for the current threading code, we'll preserve the interface while we
> reimplement.  Otherwise, we should consider ourselves free to rip out the
> old code and start afresh.
> Christoph
> _______________________________________________

More information about the parrot-dev mailing list