[asterisk-dev] Locking, coding guidelines addition

[Raj Jain]

On Mon, Jun 30, 2008 at 5:37 PM, Russell Bryant <russell at digium.com> wrote:
> Steve Murphy wrote:
>> It would seem to me that if unified the pvt and channel data (at least
>> lockwise), it would simplify the locking situation tremendously. And
>> having a channel driver just tweak pvt data wouldn't require any
>> lock-order reversals, etc.
>
> 1) You said the pvt is a subset of an ast_channel, but it's actually an
> extension of the ast_channel.  If this were C++ land, I would say that
> ast_channel is an abstract class, and sip_pvt, iax2_pvt, etc., along
> with their associated ast_channel_tech function table, are
> implementations of the abstract class.

Thanks for documenting these coding guidelines. The C++ inheritance
analogy is a good one for explaining this. If ast_channel is in
principle "abstract", then that further supports the design thought
that it shouldn't have a lock of its own.

> 2) #1 is only partially true.  The pvt structs in channel drivers get
> used for much more than simply the channel specific data for an
> associated ast_channel.  For example, the sip_pvt structure has been
> overloaded to represent all dialogs, such as registrations and such,
> even those that are not associated with a channel.

I would consider that (using sip_pvt for registrations and
subscriptions) as a design flaw. sip_pvt isn't really a "derivation"
of ast_channel for those specific usages.

--
Raj Jain