beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Thread Policy on Controls...
Date Wed, 18 Jan 2006 15:37:21 GMT
If it violates the contract, it's not a warning. (That assumes there is a
control in the shared flow)

On 1/18/06, Rich Feit <richfeit@gmail.com> wrote:
>
> I'm suggesting the warning for *any* public method that's not marked
> synchronized.  Why wouldn't this be sufficient?
>
> Daryl Olander wrote:
> > 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 <richfeit@gmail.com> 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 <dolander@gmail.com> 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?
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
>

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