Not so much api. Anyway, for all you evolution provider writers (uh, connector i guess), these calls:
- camel_store:get_folder - camel_store:get_folder_info Are no longer serialised using the CamelStore->priv->folder_lock. get_folder is already serialised, but only per-folder, so if you do any store-wide stuff in your implementation it may need tweaking. In imap we serialise things using connect_lock anyway, so it isn't an issue. In local folders we don't need to serialise (although this could lead to thrashing if you open a lot of folders in parallel - or perhaps improved startup time due to parallelism). get_folder_info doesn't really need to be serialised, afaict, except perhaps to reducing thrashing again. This is to fix a deadlock with offline mode, i hope. God knows what other bugs i've just exposed, so keep an eye out if you use imap. Startup is probably going to show any issues that exist. In the future I want to look at removing folder_lock probably entirely, it isn't really needed I think, there are other serialisation mechanisms already in place or easy to add. In the far future the same for the global CamelFolder lock, but thats less important right now. But needed to get any better performance out of imap, if a non-synchronous driver is ever written. I also want to look at just moving camel-disco-store stuff into camel-store (or service) i.e. just store the folder state the same as the service state. This should reduce the possibility of state inconsistencies and make the code a little bit simpler, it'll just be up to implementations to choose their implementation based on the current online state. CamelDiscoStore is pretty light-weight, and everthing else in imap is re-usable if its functionality is merged into another class. !Z _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
