Deprecate Threads

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


Hello.

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

-- 
Bacek

On Sun, Jan 2, 2011 at 2:10 PM, Christoph Otto <christoph at mksig.org> wrote:
> On 12/31/2010 10:50 AM, Andrew Whitworth wrote:
>>
>> On Fri, Dec 31, 2010 at 12:05 PM, chromatic<chromatic at wgz.org>  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
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list