beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Thread Policy on Controls...
Date Wed, 18 Jan 2006 15:15:48 GMT
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
View raw message