On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Stefano Bagnara ha scritto:
> >>> /**
> >>> * Method execute executes a Block within the context of a new
> >>> ConditionManager.
> >>> * @param mail
> >>> * @param block
> >>> * @return Object
> >>> * @throws SieveException
> >>> */
> >>> protected Object execute(MailAdapter mail, Block block) throws
> >>> SieveException {
> >>> // Switch to a new ConditionManager
> >>> ConditionManager oldManager = ConditionManager.getInstance();
> >>> ConditionManager.resetInstance();
> >>>
> >>> // Execute the Block
> >>> Object result = block.execute(mail);
> >>>
> >>> // Restore the old ConditionManager
> >>> ConditionManager.setInstance(oldManager);
> >>>
> >>> return result;
> >>> }
> >>>
> >>> I don't get how it works. ConditionManager.resetInstance will set the
> >>> static thread local fieldInstance to null: doesn't this invalidate also
> >>> instances of every other thread using the ConditionManager ? Shouldn't
> >>> resetInstance simply remove the conditionManager from the fieldInstance
> >>> ThreadLocal using a fieldInstance.set(null) ?
> >> Forgot to say that if this is the case it should be pretty easy to
> >> create a test case to prove it.
> >
> > how would you approach the management of the multiple threads?
>
> I'm writing the code in thunderbird, so forget syntax and other
> problems. Hope you get the idea:
>
> void testIssue() {
> ConditionManager instance1 = ConditionManager.getInstance();
>
> Thread otherThread = new Thread() {
> public void run() {
> ConditionManager.resetInstance();
> }
> }.start();
>
> otherThread.join();
>
> assertEquals(instance1, ConditionManager.getInstance());
> }
>
> otherwise, instead of checking the ConditionManager methods directly we
> could check the call to the AbstractConditionalCommand.execute.
>
> get the manager, get the condition manager instance, run the execute in
> the main thread, run the execute of another thread using the same
> pattern above, check the condition manager instance (it has to be the
> same again).
that'd probably do it
> Of course this simply prove this issue and does not check for every
> synchronization error, but I find it useful to prove bugs with tests and
> see them greened by the patch.
true
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
