[IronPython] Question about Control.Invoke and CallTargets
curt at hagenlocher.org
Tue Nov 25 16:57:13 CET 2008
Is this something that changed between 1.1 and 2.0 or do you see the same
behavior in both?
On Tue, Nov 25, 2008 at 7:47 AM, Glenn Jones
<glenn.k.jones+ipy at gmail.com<glenn.k.jones%2Bipy at gmail.com>
> Hello guys,
> We're seeing some strange behaviour when doing cross-thread invoking in
> Resolver. Unfortunately, we can't get a minimal repro for this, so I'll just
> describe what's going on and hopefully something will be obvious.
> We do our recalcs in a background thread, to avoid blocking the GUI. When a
> recalc finishes, it has to update the UI with the results of the
> calculations. We do that with:
> form.Invoke(self._synchroniseUI.Target, self, startedTime, aborted,
> where 'form' is our main form, 'self' is a Document instance that holds the
> sub-engine and all the results, `startedTime` is a DateTime, `aborted` is a
> ManualResetEvent, and `state` is an object with some state extracted from
> the recalculations.
> We have instrumented the execution of this, and we find this weird pattern:
> While _synchroniseUI takes say 500ms, form.Invoke takes 5000ms, but only the
> first time it's called. Subsequent updates behave normally. Our guess would
> be that some kind of overhead is created lazily once, and comes for free
> after that, but it's hard to see what's going on.
> We've tried the same Invoke call with CallTarget0 and a lambda with the
> arguments and with CallTarget5 with the same results.
> Is there something potentially expensive that involves CallTargets and
> cross-thread invocations? This was fine in IronPython 1.1.
> Glenn & Orestis
> Users mailing list
> Users at lists.ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users