Re: [evolution-patches] fix for bug #61551



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



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