On Wed, 2005-08-31 at 13:58 +0800, Not Zed wrote: > > which is awkward, to say the least, and not really an option for > > distributed code. > > Well you don't need to do that anyway, you could path it in a -I thing.
Sure, much better. > > Access to a locking mechanism for externally developed components is > > really necessary unless they should use homegrown solutions, which is > > not an option either I guess. > > Hmm, i'm not sure - it might depend on the particular lock. It is > probably possible to get away with not using any of those locks but just > defining your own. That's how camel-imap-* used to work, but because of > other problems (mainly complexity and races due to the the 4 levels of > interested parties, service, store, disco-store and imap-store), that > particular implementation was changed. Hmm... OK. I was of the impression that those particular locks in "camel-private.h" was of mandated use due to design issues up-source, since everybody seemed to use them. Well, I'll think something up myself then. > > I am really not qualified at all to hack on some way to extract the > > "to-be-public" parts of "camel-private.h". I would bet a really big part > > of my right arm that much in Evolution depend on hard to spot properties > > of the current implementation. > > > > Any suggestions? > > Given we are in hard code freeze, not sure; since moving it around > requires some macro changes, which i guess are code. > > Which locks are you trying ot access? Do you really need them? > Anything else in private is definitely private. I am trying to synchronize access to the url in connect() with the store lock. The url is really the only thing that I am currently aware of that I should protect (right?). The backend server is fully thread-safe so only locally shared resources are of any concern to me. Thanks, jules _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
