Re: EndInvoke still required?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Tue, 08 Jan 2008 14:31:44 -0800, Erik Funkenbusch <erik@xxxxxxxxxxxxxxxxxxxxxx> wrote:

[...]
This would be true most of the time, but at some point you're going to
have the last receive callback that occurs. This will presumably call
BeginInvoke() still, and there will never be another receive callback to
provide the opportunity to call EndInvoke().

Yes, I would obviously have to deal with this situation in some application
cleanup code. However, since the application would be ending anyways, i'm
not sure it's that important to clean up, other than for neatnesses sake.

Well, it depends on the resources being used. It does seem like in the case of Control.BeginInvoke(), no resources that have external effects would be involved and that just ignoring the cleanup would be fine.

Of course, since we've already seen reasonably good information suggesting cleaning up is unnecessary in any case, it seems odd to be even talking about under what _other_ situation cleanup might or might not be optional.

Other solutions would be similar, involving a queue processed somewhere.
You could put a timer on the Form, or run a dedicated consumer thread.
These should all be able to process _all_ of the EndInvokes() necessary.

The timer would just use unnecessary resources, running when it didn't have
to. And creating a consumer thread for this one purpose seems wasteful as
well.

Even more convoluted, you could use the Delegate async methods
BeginInvoke() and EndInvoke(), which _do_ provide a callback (so you can
easily clean those up). You could use the asynchronously invoked delegate
either to call Control.EndInvoke(), or even just to call Control.Invoke()
directly (avoiding the entire Control.Begin/EndInvoke() issue altogether
:) ).

This is a good solution actually. I see it as less convoluted and less
resource wasteful (since the delegate async threads will come from the app
worker thread pool).

I don't see this as any less wasteful than using a timer or another thread. The timer in particular should be reasonably low impact, since it takes advantage of the built-in WM_TIMER mechanism. You don't even need a new thread to service the timer, and your GUI thread needs to be processing events every now and then anyway. A single extra consumer thread isn't really that big of a deal, and it's not like queuing something on the thread pool is completely cost-free (also, using the thread pool exposes your code to congestion in the thread pool, something that Control.BeginInvoke() wouldn't otherwise have to worry about).

In other words, I don't think any of the solutions are _especially_ wasteful, and I don't see using the thread pool via Delegate-async mechanisms is obviously better, even though I think that all of the possibly solutions are probably pointless. :)

It could be packed up into a helper class, quite
easily and far less prone to maintenance errors. But, as you say, still
more work than is strictly necessary if Control.EndInvoke is guaranteed to
not be needed.

Exactly.

Pete
.

Relevant Pages

  • Re: Timer-queue timer callback proc and re-entrancy
    ... If you have a UI thread, you can use WM_TIMER, or you can use the thread pool (timer queue) and a sync object. ... the callback function can be called by different threads even if another callback is in progress. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Thread and Timer
    ... which you blocked the message pump. ... callback timers are about the most useless entities in all of Windows. ... I'd like to use a timer inside a thread. ... UINT g_iMessage; ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
    ... to delete the timer, and then manually set the frequency. ... The first is in the switch callback, ... means the call to _modify_PLLin _target worked. ...
    (Linux-Kernel)
  • Thread and Timer
    ... I'd like to use a timer inside a thread. ... CALLBACK and handle in OnTimer I never get the message. ... UINT g_iMessage; ... PostMessage, LPARAM ); ...
    (microsoft.public.vc.mfc)
  • Re: About GUIDE Data Types
    ... Could not I create application data through one GUIDE user control and call it from different one? ... If I understand what you're asking, you can access the application data stored in a figure as long as you have its handle, regardless of where (script, regular function, graphics object callback, timer callback, etc.) you're trying to do so. ... handle structure could not be reached by timer and its stop function. ... How did you set the timer function's TimerFcn to use the first function whose signature you provided? ...
    (comp.soft-sys.matlab)