Re: Introduction of the TnyLockable

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2007-01-23 at 11:50 +0100, Sergio Villar Senin wrote:
> Philip Van Hoof wrote:
> 

> > 
> > But that's just a guess. I havn't really in-depth investigated this, no.
> 
> Well, I told you that because I also didn't really understand them very
> well at first sight, and it seems that I'm getting some UI freezes if
> they're present. Once I commented all of them the freezes disappeared.
> 
> Anyway it seems that I need to review carefully that code, in order to
> fully understand it, and to see if the problem is there or at the
> application side.

Well, I would at least check with some of the gtk+ developers on why
they too did this in for example the GtkDialog and GtkClipboard code.

If it doesn't freeze in the demo ui either, I suppose we can restore any
patch if you commit commenting the lines. I know the location and I too
am watching anything related to those mainloop thingies closely at this
moment.

So if things stop working, don't worry .. we know what to do, right? :-)

Therefore, you are allowed to commit such changes and experiments at any
time. Yet it's going to be interesting to nevertheless know why things
suddenly work, or why things are the way they are (in gtk+ code).

My mistake too, I should have gotten an answer to that question before
committing what is current. I guess I was in copy-paste mode back
then :) (aren't we all sometimes? hehe)

But it's good to know that two extra eyes are looking at that piece of
code. It's by far the most complex stuff in tinymail, next to the mmap
things in camel-folder-summary.c (which is, actually, straight forward
once you checked it out and once you understand how it works).


By the way, there are some major performance improvement possible in the
summary code of camel-lite. Its locking is also not very "cool" to me. 

Same for the IMAP store code. There is recursive locking (which looks
good), but still when cancelling things .. it looks like it that code
that should have been locked gets mixed up. Causing all sorts of strange
rage conditions (like store->ostream not being a CamelStream anymore,
while it's reading the results from that TCP stream, causing errors of
course -- the errors are caught and handled, so it doesn't crash, but
the stream shouldn't have disappeared either).

Anyway .. this type of bugs (because bugs they are, indeed) is blocking
me from in-a-stable-way implement incremental message retrieval and
other such features.

So I'm aware that there are some instabilities in camel-lite. I don't
know where, as tinymail maintainer, to let contributors focus their eyes
on. Because tinymail itself too still needs a lot of work. For example
with the thread and mainloop things that you have been looking at.

Camel-lite's stability is important too (as usual, everything is
important).


heh ...