Subject: Re: Zoom/spellcheck bug.
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri Oct 27 2000 - 16:05:49 CDT
On Fri, 27 Oct 2000, Thomas Fletcher wrote:
> On Fri, 27 Oct 2000, Martin Sevior wrote:
> > On Fri, 27 Oct 2000, Thomas Fletcher wrote:
>
> [Timer problem discussed]
>
>
> Yes but that means that we go around fixing each and every instance
> of a timer to do this handshaking. It is much better to just put
> in code in the destructor of all of the timers to NULL out their slot
> and then let the event be processed as a NULL event.
Yes. I see what you mean.
> will want to create a timer in one module, delete it in
> another where the extra hand-shaking is inaccessible. I'm
> just thinking that our Timers are general purpose timers
> and can be used for a variety of things. You should only
> have to put hand-shaking in if your code needs it, not
> because of a basic element design.
>
I agree.
> > Hmm I'm not sure if your general solution will work. How do you know if
> > the pointer in the slot is valid? It is not NULL. I think a better
>
> The timer destructor sets the slot to NULL. As I said, since
> we are single threaded you don't need to lock the global slot
> array (but later a mutex/condition variable around the slots
> would prevent contention).
>
OK. I almost get it. I'd better go back and read what you said in your
first email.
> > solution is to make sure timer has returned from doing its thing before
> > deleting it. We might be able to put in some general handshaking code to
> > test this in the timer class. ie Two boolean variables.
> > m_bDontDoTimerCodeNow and m_bImDoingMyThing.
> > A callback is only executed if m_bDontDoTimerCodeNoew is False.
>
> But how do you know how many timer events might be in the queue?
> This is an OS abstraction that you might not have access to.
>
True. I did not think of this. In gtk this worked perfectly in Word Count
even when the update rate was set to 100 ms and I had a huge document.
Deleting the timer in gtk must delete pending events. I think you might
have the same problem too. See later.
> > Then m_bImDoingMyThing is set to true before jumping to the callback.
> > After returning it's set to False. The timer delete method then sets
> > m_bDontDoTimerCodeNow to True and only removes the timer when
> > m_bImDoingMyThing is False.
>
> Where are your handshaking variables when your object is deleted?
> Essentially the slot is considered a handshake ... in a very
> rudimentary fashion. If it is full, the object exists and you
> can call out with the handler, if it is empty, then your ignore
> the callout.
>
Sorry. At what point do you delete the Timer object and allow the NULL
slot to be overwritten with a new pointer?
> I know that code counts more than words, so I'll implement
> a solution and you will see how little effort (and no code
> change in any other part of the system) it takes to implement
> this solution in a general sense.
>
Well that's a challenge! My solution will have about 20 lines of code in
ut_timer.cpp and ut_timer.h. I'll test it right away :-)
> When I get time ... =;-)
>
He he. I've got 1 hour this morning. Should be more than enough :-)
Martin
This archive was generated by hypermail 2b25 : Fri Oct 27 2000 - 16:06:47 CDT