beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <>
Subject Re: Thread Policy on Controls...
Date Wed, 18 Jan 2006 14:16:13 GMT
I'm not sure this is legal.  The contract between the control and container
as far as I can tell is that we won't allow multiple threads into a control
that is marked single threaded.  At the minimum we would have to mark all
methods that access a control (and a control couldn't be public or
package-protected).  This would involve code analysis of control usage or we
would have to mark all methods synchronized.  It seems to me the safest
policy is  either 1) mark them all synchonized if controls are present in
the shared flow, or 2) not allow for single-threaded controls inside a
shared flow by failing the compile.

We are already going to be forced to make some changes to try and support
the proper request/response behavior and we will have to specifically define
the life cycle for resource events.  I don't believe there is any way to
prevent resources from being shared between threads.  I believe we are going
to have to have a warning when compiling shared flow (and global app) about
the resource issue.

On 1/17/06, Rich Feit <> wrote:
> I think we might get far by putting a warning on any public or
> package-protected method of a shared flow that's not marked with
> 'synchronized'.  What do you think?
> Daryl Olander wrote:
> > Sorry, I meant that action execution is serialized but that other
> threads
> > can run in a shared flow when the action is executing.
> >
> > On 1/17/06, Daryl Olander <> wrote:
> >
> >> Looks like the default for the thread policy on a control is single
> >> threaded.  As described in previous mails, Shared Flows and Global App
> are
> >> not single threaded.  I believe that action execution is single
> threaded,
> >> but that mulitple threads can access state and call member method on a
> >> shared flow while an action is running.  The question I have when the
> >> control JavaDoc specifies that the infrastructure must insure only a
> single
> >> thread will execute in a particular instance of that control at a time,
> does
> >> this mean the control container?  If this is true, it seems to me we
> are
> >> going to have to throw exceptions when controls that are single
> threaded are
> >> created in either a Global App or Shared Flow.
> >>
> >> Does this match others understanding?
> >>
> >>
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message