thread API

On Mon, 24 Apr 2000 11:26:27, Dan Sugalski wrote:
> I *have* been saying the current perl-level thread interface is useful
> and makes some interesting things easier, and I *have* (or, rather,
> had) been holding back my enthusiasm for it both because of the
> outstanding issues and out of respect for your statements that things
> will at some point change.

Well said.  This is the right attitude.

> I've been patching against the underlying 5005 code because that's what
> we have, and you and I see things differently enough that my coming up
> with an alternative would be a waste of both our time. We've already
> gone through that more than once. I don't particularly care how things
> are implemented under the hood. As long as things are safe that's
> irrelevant.

This is like a "work-and-see" instead of a "wait-and-see" attitude.  I
like that.  The thread model that is in place is much much better than
nothing.  Certainly it is incomplete and possibly needs to be
re-implemented with a new design, but it is also quite useable in many
situations.  It is encouraging to see that developers understand the
merits of supporting what currently exists until such time as something
better exists.  Dan is the closest thing to a champion for perl threads at
the moment, and while he has a preference for the tried and true API, he
seems to be willing to consider alternatives while still giving some
attention to the functioning thread code (and users of that functioning
model).

I still get the sense that some developers are not entirely convinced that
Perl even needs a thread model.  After all, "it's just a scripting
language, right?"  8)  The software development world is beginning to
understand the flexibility, coding efficiency, and power of high-level
interpreted languages, even for application development, and Perl is a big
factor in that.  So why are threads important?  Consider a Perl server
that must serve multiple connected clients.  Some may ask, "why would you
do that in Perl?", when they should be asking, "why not do that in Perl?".

Hopefully it is a given that robust threading should be a priority in
Perl's near development.  One reason that sticks out in my mind is that of
all language features that can be added to Perl, threading is one
functionality that can't be added by writing more Perl code.  Perhaps
someone could emulate threading concepts in Perl code, but the result
would be a thread emulator, not true threading.

As an example, unicode support could have been implemented as a Perl
module with its own API (i.e. without changes to the language itself), but
the efforts to integration of unicode support were deemed justified.  How
much more so for threads?

Please accept this email, not as an impatient demand to hurry up and get
threads working, but as encouragement not to avoid thread issues because
of the technical challenges and risks to interpersonal relationships.
Perl will get there.

• thread API by jasho
• Java thread API by jasho