On Wednesday, May 28, 2003, at 02:56 PM, Austin Hastings wrote:
(s/coroutine/thread/g for the same rough arguments, e.g. "why should the caller care if what they're doing invokes parallelization, so long as it does the right thing?")
Global variables. Threads __never__ do the right thing.
Heh. That's for sure.
I am enamored with the possibility of finding some sub-like syntax for threads where variables are shared *solely* based on their scope, because that is simply The Way It Should Work. If you're in a thread, and refer to a var outside of the threaded block, it's shared; if you refer to a lexical var within the thread, it's not shared. Much like your April example, or John M's idea of C<my> vs. C<our>. So that if:
sub process_event (Event $e) is threaded { # (A) an always-parallelized subroutine
my $z;
...
}
our $x;
loop {
our $y;
my $current_event = get_event()
or next;process_event($current_event); # (B) creates a 'process_event' thread for each event
}
$x and $y are shared between all active threads invoked by line (B), the threads can't see the lexical $current_event at all, and the lexical $e and $z are private to each individual C<process_event> thread. Bada-bing, Bada-boom, can't get much more intuitive than that.
OTOH, "threads" have proven historically easiest to manage when little if any data is shared. OTOOH, threads that "share" everything but their private lexical data would be faster/easier to create & run, because they don't have to do mass copying of program state. OTOOOH, they'd still need automatically generated locking when they _were_ accessing those shared vars. OTOOOOH, there's nothing wrong with that -- that's what threads are supposed to do, and the vast majority of speed-oriented threads don't *refer* to much shared data, and big "event loop" threads do because, well, they have to.
MikeL
