Re^5: Doing two things at once, fork question. (thread + method)

My adversion to your first method is that it doesn't work:

use threads;;
{ 
    package junk; 
    sub new{bless [], $_[0] }
    sub method{ printf __PACKAGE__ . ": @_" }
}

$o = junk->new;;
async{ sub{ $o->method( qw[ the quick brown fox ] ) } };;
## No output!

async \&junk::method, $o, qw[ the quick brown fox ];;
#outputs
junk: junk=ARRAY(0x1adcdec) the quick brown fox
[download]

Likewise your second:

... setup as above

async( $obj->can("method"), $obj, qw[ the quick brown fox ] );;
[Type of arg 1 to threads::async must be block or sub {} (not subrouti
+ne entry) at ...
[download]

Either of these do:

async sub{ $o->method( qw[ the quick brown fox ] ) };;
junk: junk=ARRAY(0x1b7d5a4) the quick brown fox

async{ $o->method( qw[ the quick brown fox ] ) };;
junk: junk=ARRAY(0x1c1b4a4) the quick brown fox
[download]

But I'm not sure that there is any benefit to the extra level of indirection.

In particular, I'm still unsure how usable objects across threads are. They now work for (some) simple cases where they did not in the early days, but I'm still uncertain that they will work properly for all cases. If the object is closed over as in most of the cases above, things seem to function because the object is subject to cloning.

But if you want to pass an object to a thread, where the object was created after the thread was spawned, or even the class was loaded after the thread was spawned, I think you're in for some surprises.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^5: Doing two things at once, fork question. (thread + method) Select or Download Code

Replies are listed 'Best First'.
Re^6: Doing two things at once, fork question. (thread + method) by tye (Sage) on Mar 08, 2008 at 03:00 UTC
The `->can` case is just Perl's broken (or at least picky and somewhat perverse) prototypes so you can work around it easily enough with: `&async( $o->can("method"), $o, ... );` [download] Note the leading ampersand. Though I wouldn't recommend this hack even if the ambersand wasn't required. The other problem was error(s) on your part. `async{ sub{ $o->method( qw[ the quick brown fox ] ) } };;` [download] Note that you used a curly brace not a paren. After fixing that I still occasionally didn't get output so I added a sleep in the main thread. I certainly wasn't trying to make the case that using objects in Perl threads were worthwhile, obviously. But I'm not sure that there is any benefit to the extra level of indirection. I consider "not hard-coding method selection" a fine benefit, especially since what class a method actually comes from is an implementation detail that the user of the object shouldn't be bothered with much less be relying upon. Then there is the possiblity of an object that is aware of "method" context and so breaks with your hack. Adding a simple pair of braces (with or without "sub", depending on your paren choices and the vagaries of Perl prototypes) to a normal method invocation seems a much better idea than hard-coding a method selection and then listing the object after that. The benefit on clarity of code (even if the code mostly doesn't work because Perl threads still rather suck) is quite significant. - tye	[reply] [d/l] [select]
Re^7: Doing two things at once, fork question. (thread + method) by BrowserUk (Patriarch) on Mar 08, 2008 at 10:08 UTC
I consider "not hard-coding method selection" a fine benefit, especially since what class a method actually comes from is an implementation detail that the user of the object shouldn't be bothered with much less be relying upon. Okay, I see where you are coming from. I guess that reflects how little use I make of Perl's OO. It was my expectation that taking a reference to a method would do whatever method resolution was required. I even tried it out: `C:\test>p1 use threads;; { package t1; sub new{ bless [], $_[ 0 ] }; sub method{ print __PACKAGE__ . ": @_" } };; { package t2; our @ISA = 't1'; sub method2{ print __PACKAGE__ . ": @_" } };; $o = t2->new;; print $o;; t2=ARRAY(0x22b00c) $o->method2( 1 .. 5 );; t2: t2=ARRAY(0x22b00c) 1 2 3 4 5 $o->method( 1 .. 5 );; t1: t2=ARRAY(0x22b00c) 1 2 3 4 5 print \&t2::method;; CODE(0x22afac)` [download] Of course the problem was I didn't look closely enough at that coderef to realise that it had a autovivfied a coderef for an inherited method. If I had tried invoking it: `\&t2::method->( 1 .. 5 );; [Undefined subroutine &t2::method called at (eval 13) line 1` [download] but what is worse, having taken that reference to the inherited method, it permentantly screws up the method resolution: `$o->method( 1 .. 5 );; [Undefined subroutine &t2::method called at (eval 14) line 1` [download] Nasty! This is certainly the case in other OO languages I used that support first class functions and OO. I don't recall ever having a problem passing a method around in Smalltalk, D, Q, Clean, Mozart, Ocaml, .... Even C++ has delegates these days. Is it surprising that Perl OO and threads don't mix well, when Perl OO is so fragile? /me will wait patiently for Perl6 before I get heavily into writing OO Perl methinks. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]