From: Ñ©ËÉ ¹ù
Sent: Monday, March 23, 2009 7:41 PM
To: <pike[at]roxen.com>
Subject: RE: thread and lambda
> To: <pike[at]roxen.com>
> From: <6341[at]lyskom.lysator.liu.se>
> Subject: Re: thread and lambda
> Date: Mon, 23 Mar 2009 10:05:03 +0000
>
> How about
>
> mapping n=([]);
>
> void main()
> {
> mixed c=lambda(string s)
> {
> string k,b;
> sscanf(s,"%s=%s",k,b);
> n[k]=b;
> };
no warning is ok, when a variable is put in a class, the programmer has more
probability to care for it against thread
>
> function c2(string s)
> {
> string k,b;
> sscanf(s,"%s=%s",k,b);
> n[k]=b;
> };
no warning is ok
>
> mapping m=([]);
>
> function d(string s,mapping mloc)
> {
> string k,b;
> sscanf(s,"%s=%s",k,b);
> mloc[k]=b;
> };
>
> Thread.Thread(...c2,m... );
> }
no warning is ok, the programmer clearly pass the arg to a thread, he know
what he was doing.
>
> You'd end up warning for everything, or missing a lot of cases where
> you might do something wrong. If c and c2 shouldn't be warned for,
> consider
>
> void foo()
> {
> mapping n=([]);
>
> void main()
> {
> mixed c=lambda(string s)
> {
> string k,b;
> sscanf(s,"%s=%s",k,b);
> n[k]=b;
> };
>
> Thread.Thread(c);
give a warning! the programmer may not conscious that he was using a var out
of the current function
> };
>
> main();
> }
>
> In d, the function looks ok, but the mapping is still not local
> because of how it's used. Since most datatypes are destructive, it
> might very well change value under foot, to take the first example:
>
> class Counter { int x; };
> Counte r my_counter=Counter();
> for(my_counter->x=0;my_counter->x<100;my_counter->x++){
> Thread.Thread(lambda(){
> write("%d\n",my_counter->x);
> });}
give the warning! the programmer may think the my_counter is local var.
>
> Counter my_counter;
> for(my_counter->x=0;my_counter->x<100;my_counter->x++){
> Thread.Thread(lambda(Counter local_counter){
> write("%d\n",local_counter->x);
> },my_counter);}
not nee warning. when the guy pass sth. in to a thread clearly, he should
know what he is doing by himself.
>
> And the other problem is that I wouldn't really know where to start
> untangling stuff to be able to give useful warnings, since the warning
> has to be when you use a function pointer, which is fairly anonymous.
It seem that the old _typeof bug can indicate what function reference the
var no t in the environment of the current function.
>
See all the ways you can stay connected to friends and family
|