Subject: Re: Deferred events and ugly pointers [was: Win32 & timer]
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Nov 15 2000 - 03:00:01 CST
On Tue, 14 Nov 2000, Mike Nordell wrote:
> Martin Sevior wrote:
> > On Sun, 12 Nov 2000, Sam TH wrote:
> > > This has to do with the whole idea of modeless dialogs, which I actually
> > > like quite a lot.
>
> They are not something I would want to be without. But there's nothing that
> can't be improved. :-)
>
Sure :-)
> >
> > I think that doing things this way (with the timer) is a defensible way of
> > working around not running a background thread. Tacking a list update to
> > every cursor motion could really slow down performance.
>
> That seems like a good reason. But, since it's not multi-threaded, it still
> (at some point in time) interrupts the "main" thread to update the dialog.
> Well, even if it was multi-threaded it would need to lock the main data to
> prevent the input thread from changing stuff while the dialog did read it.
>
> Since this "idiom" is used in more than one dialog, I was playing with the
> idea of moving this behaviour into a more self-contained entity. A
> deferred/bundling event generator.
>
> I use the lists dlg as example here.
> The lists dlg subscribes to deferred/bundled events of (at least) type
> AV_CHG_MOTION and AV_CHG_FILENAME.
> The main execution context (the one handling cursor movements and so on)
> fire deferred events like "OK, we have made a change to the document, and we
> had no input for n ms. It's time we fire an event". When this time comes, it
> only broadcasts the last change event (of each specific type).
>
> I see some benefits with this approach.
> The mechanism could be implemented in XP code.
> The code to do this only exists in one place.
> The code is giving the explicit promise that it is run in the context of the
> document the update belongs to, and that the document can't change for the
> duration of this callback.
> The update messages will only be broadcast in case the document really have
> changed (current implementation polls at fixed interval).
>
Ok A few points on this. This is clearly safer in general than what we
currently do. Although in the case of the List dialog our examination of
the document is unlikely to ever cause a problem since it just reads the
list information at the current insertion point. We could get into trouble
during a big undo though.
It might be hard to block other Abi operations during these update events.
In the case of unix the code just sits in the mainloop waiting for
something to happen. I guess we would have to write some xp code to block
all events during the update. I think I know how to implement this in gtk.
The xp is certainly nice. The implementation details may well be pretty
tricky. We'll want some nice classes that make it easy to
register/deregister a listner. The current scheme used by the PieceTable
to update the Layout's has some nice example code.
> The possible drawback I see is that with the current implementation every
> modeless dialog can itself decide its update frequency. With my proposed
> implementation this time will have to be the same for all listeners to this
> deferred/bundling event generator (not really true, but let's assume it for
> simplicity). Would this be a problem?
>
The WordCount dialog allows you to adjust the update rate. (Reminder to me
to fix this so that it only updates if the local tick is different from
the gloabl tick).
> > However Mike, I'm surprised you haven't yet bitterly complained about the
> > really ugly way I construct the unique (void *) pointers needed for the
> > fake list elements used in the preview. Feel free to explain the right way
> > to do this :-) Remember every pointer must be unique.
>
> I just haven't come to see it yet. :-)
>
> If the code is the one in AP_Dialog_Lists::generateFakeLabels(), the first
> thing I noticed was that we apparently have an array of four app objects.
The first one points to app, the next one to app++, the next to app++
etc.....
> Also, they are compatible with the type PL_StruxDocHandle. That was
> something of a surprise to me! :-)
>
Type PL_StruxDocHandle is just a typedef (void *). See pd_Document.cpp for
how these void * pointers are registered to a UT_Vector of executable
listners. When I finally grokked that code I was I really impressed and
scared.
> However, if the only reason to do this is to get unique pointers (that are
> never dereferenced I'd hope), what about
>
> m_pFakeSdh[i] = reinterpret_cast<PL_StruxDocHandle>(new char);
>
> ? :-)
I'll check that out. Will m_pFakeSdh[i] point to an executable area of
memory with this cast? If it doesn't we may get a segfault. Anyway I'll
try it.
Martin
This archive was generated by hypermail 2b25 : Wed Nov 15 2000 - 03:00:06 CST