[Evolution-hackers] Camel unreferencing question



Camel hackers,

It's not clear from the gtk-doc API documentation* whether or not you
must unreference a store after getting it using camel_session_get_store

*) http://pvanhoof.be/files/libcamel-api/html/CamelSession.html

.
.
.

Actually, it's not clear for most CamelObjects whether or not you should
do that. 

I have filed multiple bugs about this already. But it really looks like
the "very few people care"-phenomena or the totally wrong "it works for
Evolution so it's not broken"-thinking is happening here:

No replies, not even a bug confirmation or marking the bug as invalid.

Some bug examples (they might be outdated or wrong, I stopped checking
them and started implementing workarounds because I simply can't wait
for months for such bugs to be looked at).

http://bugzilla.gnome.org/show_bug.cgi?id=343882
http://bugzilla.gnome.org/show_bug.cgi?id=343683



I would also like to point out that Camel often crashes on the
check_magic method for CamelObject types that you implemented yourself
(like the CamelSession implementation you have to provide to Camel).

This check_magic method seems to happen each time you do the macro
casting: CamelSession *session = CAMEL_SESSION (thingy)

CamelSession *session = (CamelSession*) thingy, however, works
perfectly. Debugging sessions, however, revealed that the instance
"thingy" is healthy and fully correct. It also seems to be a race
condition or at least something that doesn't always happen.

Making me wonder: Why not simply replace CamelObject with GObject? And
what is this "check_magic" thing anyway? It seems to loop over a
inheritance tree or something like that.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be




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