[Asterisk-code-review] astobj2: Assert on attempt to lock object with no locking. (asterisk[master])

Corey Farrell asteriskteam at digium.com
Tue Oct 2 14:38:24 CDT 2018


Corey Farrell has posted comments on this change. ( https://gerrit.asterisk.org/10376 )

Change subject: astobj2: Assert on attempt to lock object with no locking.
......................................................................


Patch Set 1:

> > > I'm not in favor of this.  You currently don't need to care
 > what
 > > > locking mechanism is on an object to lock/unlock it.  The only
 > > > exception is for recursively locking an object because rwlocks
 > > are
 > > > not recursive.
 > > >
 > > > You could create the same type of object but with different
 > > locking
 > > > mechanisms if you want.
 > >
 > > My idea is that the following should be an error:
 > > void *obj = ao2_alloc_options(0, NULL, AO2_ALLOC_OPT_LOCK_NOLOCK);
 > > ao2_lock(obj);
 > >
 > > If we explicitly disable locking for an object then later try to
 > > lock the same object, it's likely a bug and we should either
 > > re-enable locking for that object or stop trying to lock it.
 > 
 > The point is that the particular code may not know the object even
 > has a lock.
 > 
 > IIRC There may still be frame format code that may or may not have
 > a lock on the object.

I still think it would be useful if testing could identify those situations but I'll abandon this.


-- 
To view, visit https://gerrit.asterisk.org/10376
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I5518e55739769792a76f766ce25880d7d944f63b
Gerrit-Change-Number: 10376
Gerrit-PatchSet: 1
Gerrit-Owner: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: Jenkins2 (1000185)
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Tue, 02 Oct 2018 19:38:24 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20181002/e1e376f6/attachment.html>


More information about the asterisk-code-review mailing list