>
> use Thread;
>
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
> async { ... };
> $result = join $thread;
>
> $thread = this Thread;
> @threads = all Thread;
>
> $thread1 == $thread2 and ...
> yield();
>
> critical { ... }; # one thread at a time in this block
>
> $mutex = new Mutex;
> lock $mutex;
> $ok = try $mutex;
> unlock $mutex;
>
> $semaphore = new Semaphore $initial;
> $ok = $semaphore->up($n);
> $semaphore->down;
>
> $event = auto Event;
> $event = manual Event;
> set $event;
> reset $event;
> wait $event;
>
> $timer = Timer->delay($seconds);
> $timer = Timer->alarm($time);
> $timer->wait;
>
> $readable = $fh->readable;
> $writable = $fh->writable;
> $failure = $fh->failure;
>
> $ok = wait_all(@objects);
> $i = wait_any(@objects);
>
I'm not completely sure what you are trying to do with this RFC. At first
glance I had thought you were unaware of the existing option for
multi-threading since 90% of what you're asking for is already present. As
I read on, you seem to suggest that you merely want stylistic changes to the
existing proto-types for threads. Seemingly influenced by win32 (I won't
start a holy war).
I'm afraid to say anything because you obviously know what you're talking
about, but many of your changes seem pointless since they are completely
possible today. For example.
Why redo Semaphore, when we have Thread::Semaphore... I also noticed that
you neglected to mention another very useful entity, Thread::Queue (which I
use more often than semaphores). So you must not have been copying verbatum
from perl5.5+. 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.
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. For example:
You suggest:
critical { ... }.
Novel, and similar to java's synchronize(entity) { ... }, though not as
flexible. A better recommendation would have been critical (entity) {
... }. But you suggested that the combersome alternative would have been:
{ lock $mutex; ... unlock $mutex }
But the current threading model allows
{ lock $var; ... }
Once fallen out of scope, the lock is broken. As for the raw critical
section. You could merely perform. In general you seem to want to throw
away all scope-based threading operations, which I look at as a step
backwards.
sub foo_section { lock &foo_section; ... }
foo_section();
Locks on subroutines are essentially the same as locked blocks.. The obvious
disadvantage is the scope. But again, the scoped lock of _any_ perl
variable takes care of this situation, so a new keyword is not necessary.
If that's not fine tuned enough for you, you can completely emulate Java's
method-synchronize prefix by the following:
{
package Foo;
sub method : method, locked { ... }
}
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 get the impression that you're goal is to windowfy perl's threading
model.. Shaaaame. If this were a first pass at threads, then I might
advocate it (since win32 isn't bad at all), but we already have perl5005
threads. They work (with known limitations), so totally changing the syntax
around would break compatibility. Not that these elements were ever
sanctioned or supported in the first place, but why change things just for
the sake of changing them?
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.
That said, I like the timer, and file-handle signals/ events. No reason why
the current experimental threading couldn't be extended.
In summary, the existing threading model actually seems more powerful than
your proposed one. But there's plenty of room to add new features..
Especially since it's modularized and should stay that way (e.g. not
strictly part of the core). Argument being: Linux, as an example, is not
very friendly to multi-threading.. So it should only be used when actually
needed. Not that perl is focused around Linux, but this just goes as an
example of imposing a system model that is less than optimal for the general
case. (For the uninitiated, the instantiation of the first thread requires
creation of TWO heavy-weight threads (Linux treats threads as merely
processes that share the same memory page-table) ).
What I would suggest is that you reimplement the various cleanups ( like
events replacing cond_xx ) as modules. This hides the details just like
IO::Socket. Thread::Event just seems very clean to me. You could even make
IO::Event, and incorporate that as part of IO::Handle when threading is
enabled.
I also like your notion of de-intifying thread-id. I agree that we should
be isolated more from the threading model (since it is supposed to be cross
platform). Hell, we're isolated from file handles pretty well (unless you
go around extracting the handle number). The whole incremental and wrapping
tid has always bothered me.
