Deprecate Threads

[Andrew Whitworth]

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.

It would be a different story if the threading system was working,
functional, and relied upon by our current users. In that case there
is a real argument to be made about not throwing the baby out with the
bath water. The way the system is now, we would end up putting a
pretty new face on a broken system. And what does that buy us? When
we're putting together this new API, are we trying to maintain the
broken behavior we have now, or are we going to be disregarding
existing behavior in the interests of putting in a good API?

If we remove this system first instead of trying to put a new API on
it, we can start from the ground-up with new assumptions. Are we
following the POSIX model of threads? Does each ParrotThread represent
a separate interpreter running on it's own OS thread, or do we look
for something more lightweight/heavyweight/flexible/powerful? When we
create a new thread are we going to be cloning PMCs or locking/sharing
them? How are we sharing data between threads? Can multiple
interpreters run on a single OS thread? Can one interpreter be
multiplexed across multiple OS threads?

If we put a new API on the existing system and try to maintain it's
behavior through the reimplementation, I suggest that we are going to
be stuck with a certain set of design assumptions and I also suggest
that we aren't buying anything with the extra effort.

I may be overlooking something worth saving, but the opinion in my
head right now is that the system is not worth the effort to save.

--Andrew Whitworth