> I'm not completely sure what you are trying to do with this RFC.
This RFC describes the programming interface to Perl6 threads.
It documents the function calls, operators, classes, methods, or
whatever else the language provides for programming with threads.
Perl5 has a thread interface, but I'm not satisfied with it. It lacks
features that I want, parts of it seem graceless, and too much of
PThreads shows through.
This RFC describes the thread interface that I want.
If you don't ask, you won't get it.
> 90% of what you're asking for is already present
True. I still want it documented. And I want to make sure that
features in the Perl5 interface that I want don't vanish in Perl6,
either through oversight, implementation difficulties, or a difference
in vision. Remember, everything is up for grabs in Perl6.
> you seem to suggest that you merely want stylistic changes to the
> existing proto-types for threads.
Once you have a Turing machine, all else is stylistic...
> but many of your changes seem pointless since they are completely
> possible today.
Once you have a Turing machine, everything is completely
possible...but that doesn't mean we want to program Turing machines.
My hidden agenda is to create a good native thread programming model
for Perl6. Once you have threads and a few synchronization primitives,
you can build anything else you want, but most people won't.
Most people will code directly to the native language facilities, and
when they need the functionality of higher-level constructs, like
scoped locks, or Semaphores, or Queues, they will implement it
hap-hazardly, inconsistently, in open code, with bugs, without unit
tests, and their code will be a mess, and they will spend hours and
hours chasing race conditions.
I liken the situation to X Windows/Motif, which has (IMO) poor
graphical design, and justifies it on the grounds that the users can
configure everything to their liking. I don't *want* to configure
Motif. It's a hard problem, and I'm not specially good at it. I want
someone who is good at graphical and UI design to do it for me, and
provide the results as the default Motif installation.
If we want Perl6 threads to be useful, we have to provide an interface
that is natural and intuitive, and satisfies the needs of the
programmers.
> Why redo Semaphore, when we have Thread::Semaphore...
Thread::Semaphore is fine. In fact, Mutex, Semaphore, Event, and Timer
should probably all be dropped into the Thread:: package.
> I also noticed that you neglected to mention another very useful
> entity, Thread::Queue
Yes. We should provide Thread::Queue. I'm used to building Queues out
of a List and a Semaphore, so I didn't have the interface in my head.
> Since you've already pointed out the style "$thread = new
> Thread ...", you can't seriously be suggesting that the object/class
> definition be built into perl. Though it's possible, it's just not done.
I don't understand your point here.
In Perl5, Thread.pm is mostly XSUBs. Whether threads need core support
in Perl6 or are implemented entirely outside the core is an
implementation issue.
> Next is the explicit use of mutex's. What's the point, when just about
> anything can already be locked.. And in a much cleaner fashion than explicit
> mutex's IMHO.
mmm...you're right. And I'd forgotten about scoped locks (again,
because I'm used to building them myself.)
> But the current threading model allows
> { lock $var; ... }
> sub foo_section { lock &foo_section; ... }
> foo_section();
You're right. I didn't realize that lock($var) created a scoped lock.
I still like
critical { ... }
both because it is visually lightweight, and because in opens
possibilities for an optimized implementation. But it isn't a
must-have, and the benefits it provides have to justify creating new
syntax and taking a new keyword.
> I'm not completely sold on the scrapping of cond_xxx for events. I don't
> really see them as easier to read.. Granted I did a lot of head-scratching
> the first time I went through them, but once you get them, they're very
> powerful and intuitive.
I'm still scratching my head over them. Perhaps you could submit an
RFC documenting their behavior and showing how to use them.
> Seemingly influenced by win32
> I get the impression that you're goal is to windowfy perl's threading
> model.
My goal is stated above.
I am influenced by my experience with the Win32 thread model.
> We already have perl5005 threads.
Is anyone using Perl5 threads?
I couldn't even get 5.6.0 to compile with threads turned on.
> Lastly, you muddled over which of the various ways of instantiating a thread
> is most desirable? Perl's all about choices; I have absolutely no problem
> with the multiple interfaces.
Oh, I agree. I was just providing some motivation for the three
different mechanisms.
> What I would suggest is that you reimplement the various cleanups ( like
> events replacing cond_xx ) as modules.
Modules are fine.
I still want to put the interfaces up for discussion now. One of my
experiences with threads is discovering late in a project that you
can't do what you need without some kind of language support that you
don't have. I want to make sure that doesn't happen with Perl6
threads.
- SWM
