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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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? > >>>> > >>>> > >>>> > >>> > > > > >
