Re: [aspectj-users] A question about cflow across threads

[Pengcheng Wu <wupc@xxxxxxxxxxx>]

First, I think the current cflow implementation is consistent with its
defined semantics, i.e., to capture any join point that is within the
dynamic extent of some other join point.

Second, I also think that it would be a valuable
pointcut that enables reasoning about in which context the thread was
spawned. It looks like cflow but not exactly. I can imagine a
scenario in which a method may be called from different threads,
each of which was spawned in different calling contexts, and one
want to deploy different advice to that method depending on from
which context a thread was spawned. Probably threadflow(pointcut) will do
the job if I understand its meaning correctly.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Pengcheng Wu,  PhD Student
  College of Computer and Information Science
  Northeastern University
  Boston, MA 02115, USA




On Wed, 9 Mar 2005, Wes Isberg wrote:

> It is a good question and an outstanding issue.
>
> At one point Gregor wrote an email about using a trampoline to extend
> cflow across threads, but I can't find it at present.  It would be nice
> to find that, and/or to implement something with InheritableThreadLocal.
>
> However, since cflow is defined to be false after the original join
> point returns, there's a weird effect that the spawned thread would
> start in the cflow but could all of a sudden not be in the cflow.
> While one might want to define the semantics for cross-thread control
> flows in a new PCD "threadflow({pointcut})" to adopt the topmost entry
> point in the thread as the cflow top, it would result in a similar weird
> effect that the context available from the original top join point might
> not correlate to the top or to any running join point.  It's a race whether
> "lower" join points could affect the "top" one before it completes.
> This could be a great way to write memory leaks.
>
> I'd like to know if users who need this have deployed
> InheritableThreadLocal flags tested in if(..) clauses.  That might
> tell us how many people really need this and what they use it for.
>
> Wes
>
> > ------------Original Message------------
> > From: Pengcheng Wu <wupc@xxxxxxxxxxx>
> > To: "AJDT USER" <aspectj-users@xxxxxxxxxxx>
> > Date: Wed, Mar-9-2005 11:46 AM
> > Subject: Re: [aspectj-users] A question about cflow across threads
> >
> > Please just ignore this question now. I think it does make sense the
> > program behaves like that.
> >
> > --Pengcheng
> >
> > On Wed, 9 Mar 2005, Pengcheng Wu wrote:
> >
> > > Dear all,
> > >
> > > I have a question about cflow pointcut across threads. Assume I have
> > a
> > > program like this:
> > >
> > >  class A {
> > >    public static void main(String[] args) {
> > >      A a = new A();
> > >      a.foo();
> > >    }
> > >    public void foo() {
> > >      Thread t = new MyThread(this);
> > >      t.start();
> > >    }
> > >    public void bar() { test();}
> > >    public void test() {}
> > >  }
> > >
> > >  class MyThread extends Thread {
> > >    A a;
> > >    public MyThread(A a) {this.a = a;}
> > >    public void run() {
> > >      a.bar();
> > >    }
> > >  }
> > >
> > > The only thing interesting here is that a thread is started in the
> > body of
> > > method foo().
> > >
> > > If I have an aspect, say:
> > >
> > >  aspect B {
> > >   pointcut p(): call(* *.bar()) && cflow(call(* *.foo()));
> > >  }
> > >
> > > Will p() capture the call to bar() during the execution? If it were
> > single
> > > thread program, it will capture; but as a multi-thread program as
> > shown
> > > above, it doesn't. I am trying to figure out why it is so or it is
> > just a
> > > bug.
> > >
> > > Thanks a lot!
> > >
> > >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >   Pengcheng Wu,  PhD Student
> > >   College of Computer and Information Science
> > >   Northeastern University
> > >   Boston, MA 02115, USA
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>