Re: libtinymailui-gtk model notifications



On Wed, 2008-01-02 at 12:41 +0100, Sergio Villar Senin wrote:
> Hi
> 
> the gtk models issue the notifications using timeouts to put them into 
> the main loop, but with the "new" async queue systems, the models 
> receive the notifications from the main loop so no need to do that at 
> all, or am I wrong?

Contrary in fact. Since everything runs in the account's queue, the
tny_list_prepend call is 'always' called by another thread than the
mainloop's thread. I fear that therefore those timeout tricks are
needed :-\

Although it should indeed be possible to just assume that the prepend is
always called from a thread, (and therefore always use the gdk lock),
from an API perspective I don't think that's right.

Improvements for the TnyGtkHeaderListModel is of course, however, always
welcome.

For performance improvements, you can consult Kris Rietveld (kris on
GimpNet), since he wrote a lot of the GtkTreeView things. He's aware of
the difficulties that I have had with supporting large models being
filled up by threads.

Note that since Modest view's model is a sorted one, each row_inserted
that takes place causes a sort routine of all items (since they are
already sorted, it's of course not as expensive as an unsorted sort, but
still).

What I propose is to use a btree based sortable model implementation.
That way will the sorting routine be far less expensive (since you
flow-in the new item, rather than add it and then sort all again).

Interesting is also the Judy tree array thing (search on sourceforge) if
you want one that really scales very well:

	Contrary to btree does a Judy tree take into account cache lines: its
design tries to group node operations together per cache line. On a
device, like the Nokia device, that has relatively slow memory access ..
this is very interesting of course.

	judy.sourceforge.net


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]