[389-devel] please review: Ticket 456 - improve entry cache sizing

2012-12-10 Thread Mark Reynolds
https://fedorahosted.org/389/ticket/456 https://fedorahosted.org/389/attachment/ticket/456/0001-Ticket-456-improve-entry-cache-sizing.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/list

[389-devel] Please review: [389 Project] #536: Clean up compiler warnings for 1.3

2012-12-10 Thread Noriko Hosoi
https://fedorahosted.org/389/ticket/536 https://fedorahosted.org/389/attachment/ticket/536/0001-Trac-Ticket-536-Clean-up-compiler-warnings-for-1.3.patch Description: Cleaning up compiler warnings by: - declaring config_get_schemamod in proto-slap.h - putting parentheses around assignment - ex

[389-devel] Please review: [389 Project] #531: loading an entry from the database should use str2entry_fast

2012-12-10 Thread Noriko Hosoi
https://fedorahosted.org/389/ticket/531 https://fedorahosted.org/389/attachment/ticket/531/0001-Trac-Ticket-531-loading-an-entry-from-the-database-s.patch Bug Description: When loading an entry from the backend, it is known to be well formed and str2entry_fast() could be used, but always str2ent

Re: [389-devel] Revised: Ticket 509 - lock-free access to be->be_suffixlock - future reference

2012-12-10 Thread Mark Reynolds
Ludwig, In the future, can you make all comments of fix reviews in the trac ticket? We actually never discuss reviews on mailing lists - only in the trac tickets. Rich missed your comments about this bug. Thanks, Mark On 12/10/2012 10:57 AM, Ludwig Krispenz wrote: And I think be_addsuffix

Re: [389-devel] Revised: Ticket 509 - lock-free access to be->be_suffixlock

2012-12-10 Thread Muditha Dissanayaka
lets start it using CUDA On Mon, Dec 10, 2012 at 9:48 PM, Mark Reynolds wrote: > > > On 12/10/2012 10:57 AM, Ludwig Krispenz wrote: > >> And I think be_addsuffix is not safe. >> >> If two threads try to add a suffix, both can get the same current count, >> the both set the new suffix >> be->be_s

Re: [389-devel] Revised: Ticket 509 - lock-free access to be->be_suffixlock

2012-12-10 Thread Mark Reynolds
On 12/10/2012 10:57 AM, Ludwig Krispenz wrote: And I think be_addsuffix is not safe. If two threads try to add a suffix, both can get the same current count, the both set the new suffix be->be_suffix[count]= slapi_sdn_dup(suffix); and then both increment count. the increment is atomic, but

Re: [389-devel] Revised: Ticket 509 - lock-free access to be->be_suffixlock

2012-12-10 Thread Ludwig Krispenz
And I think be_addsuffix is not safe. If two threads try to add a suffix, both can get the same current count, the both set the new suffix be->be_suffix[count]= slapi_sdn_dup(suffix); and then both increment count. the increment is atomic, but the assignment could be done to the wrong index.

Re: [389-devel] Revised: Ticket 509 - lock-free access to be->be_suffixlock

2012-12-10 Thread Ludwig Krispenz
Hi Mark, in the locked version the list of suffixes cannot be changed while you loop over them. In your version you get the suffix count and the do a for loop i=0..count on it. Although suffixes don't get deleted from the array there couls be cases where one is added from the time you get the