[Asterisk-code-review] main/cdr.c: Alleviate CDR deadlock (asterisk[15])

Matthew Fredrickson asteriskteam at digium.com
Wed Jun 27 04:05:53 CDT 2018


Matthew Fredrickson has posted comments on this change. ( https://gerrit.asterisk.org/9270 )

Change subject: main/cdr.c: Alleviate CDR deadlock
......................................................................


Patch Set 3:

(9 comments)

https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c
File main/cdr.c:

https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3787
PS3, Line 3787: 	int nextms = 0;
> No need to initialize nextms.  You always initialize it below.
Done.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3796
PS3, Line 3796: 	/* manually reschedule from this point in time */
> Comment isn't quite right anymore.  How about:
Done.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3799
PS3, Line 3799: 	if (!nextms) {
              : 		/* I hate doing this, but previously if you set the batch time to 0, it would continuously
              : 		   resubmit batches to the scheduler.  IMHO that seems buggy, but I'd rather not break it
              : 		   if someone was relying on that behavior */
              : 		nextms = 1;
              : 	}
> I'd say it is buggy.  All they are doing is needlessly loading their CPU wh
Ok, I'll drop this code then and fix it in parse_config()


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3807
PS3, Line 3807: 	/* returning zero so the scheduler does not automatically reschedule */
> This comment is not needed anymore as you never return zero now.
Done.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3884
PS3, Line 3884: 	/* Don't call start_batch with cdr_batch_lock held */
> s/call start_batch/submit a batch/
Done


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3899
PS3, Line 3899: 		/* this only can happen if someone sets there batch time to 0 or does 'cdr submit' from the CLI back to back quickly */
> Restore the previous comment as there will normally not be an empty schedul
Done.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@3910
PS3, Line 3910: 		ast_debug(2, "Processed %d scheduled CDR batches from the run queue\n", numevents);
> This debug msg isn't quite right.
Not part of my original diff, but I can fix regardless.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@4410
PS3, Line 4410: 	SCOPED_LOCK(batch, &cdr_batch_lock, ast_mutex_lock, ast_mutex_unlock);
> This scoped lock can cause a deadlock when you call start_batch_mode().
I agree.  Removed the scoped lock.


https://gerrit.asterisk.org/#/c/9270/3/main/cdr.c@4424
PS3, Line 4424: 	/* Kill the currently scheduled item */
> This comment needs to be removed.
Done.



-- 
To view, visit https://gerrit.asterisk.org/9270
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 15
Gerrit-MessageType: comment
Gerrit-Change-Id: I6333e865db7c593c102c2fd948cecdb96481974d
Gerrit-Change-Number: 9270
Gerrit-PatchSet: 3
Gerrit-Owner: Matthew Fredrickson <creslin at digium.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Matthew Fredrickson <creslin at digium.com>
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Wed, 27 Jun 2018 09:05:53 +0000
Gerrit-HasComments: Yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20180627/e42a4da0/attachment-0001.html>


More information about the asterisk-code-review mailing list