On 12/31/2010 10:50 AM, Andrew Whitworth wrote:
On Fri, Dec 31, 2010 at 12:05 PM, chromatic<[email protected]> 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
