On Fri, 2004-07-16 at 11:44 +0800, Not Zed wrote: > On Thu, 2004-07-15 at 13:32 -0400, Jeffrey Stedfast wrote: > > On Thu, 2004-07-15 at 15:12 +0800, Not Zed wrote: > > > > > > This doesn't look good, shouldn't be poking the other folders > > > internals, more than it already is anyway. > > > > > > I think it would be better to just not call camel_folder_refresh_info > > > with the connect lock held. Infact since we're only comparing the > > > current folder which is the only lockable item, it should be safe to > > > remove the connect locks enitrely. refresh_info will lock in the > > > right order. > > > > ok... if we remove the connect_lock, isn't there a race checking dest != > > current? > > > > or maybe that just doesn't matter...? > No, becuase we don't actually dereference the pointer. > > What could happen? > > we lock > we read the pointer (atomic operaiton) > we update > we unlock > > or with no locking > we read the pointer > we go to start updating > the pointer changes > we keep updating, getting the folder/connect locks in the process > we unlock > > the updating process will set the current folder back anyway. > > and the other option > > we read the pointer, it is the same, so we do nothing > then another thread locks and changes the pointer > -> effectively no difference. > > the summary count lookup is locked anyway > and the folder_refresh_info is locked too. > > the connect lock is only protecting the pointer read, which is atomic > anyway. ok, patch committed to CVS that only removes the connect_lock stuff. Jeff -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature