| Summary: | ASTERISK-22040: Remove the bridge pointer from ast_channel; refactor consumers of the bridge pointer to safely get it through bridge_channel | ||
| Reporter: | Matt Jordan (mjordan) | Labels: | |
| Date Opened: | 2013-07-07 20:48:11 | Date Closed: | 2013-08-09 14:37:08 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Core/Bridging |
| Versions: | 12 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Unfortunately, we probably shouldn't have put the {{bridge}} pointer on the channel object. Channels can be moved around in the bridging system, and hence it isn't safe to access the {{bridge}} pointer on the channel without first locking the bridge.
It is safe, however, to use the {{bridge_channel}} pointer. What is needed is a way to *ask* the bridging framework for a reference to the bridge that the channel happens to be in. {noformat} /* BUGBUG the bridge pointer must change to an ast_channel_bridge pointer because it will never change while the channel is in the bridging system whereas the bridge could change. */ struct ast_bridge *bridge; /*!< Bridge this channel is participating in */ {noformat} | ||
| Comments: | By: Matt Jordan (mjordan) 2013-08-09 12:32:33.418-0500 This isn't really an issue. So long as channels are careful in how they use the {{ast_bridge}} pointer, there's no harm in having a direct pointer back to the bridge that the channel is in. This pointer has become so useful that removing it would probably be more intrusive than simply being careful. | ||