RFC: talloc contexts / automatic free at select loop

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Mar 20 11:06:16 UTC 2019


Some additions below.

On Wed, Mar 20, 2019 at 10:52:46AM +0100, Harald Welte wrote:
 
> Where is this useful?  There's at least two common use cases:
> 
> * allocation of message buffers without having to worry about msgb ownership

I forgot here that this obviously only works if the msgb is created + consumed
within the same select dispatch.  If e.g. the msgb is enqueued on a transmit queue,
you would have to talloc_steal() / talloc_reparent() it to a different context
before returning from the select dispatch.

In terms of our usual use cases, I see the following scenarios:

a) incoming, locally handled message

   The msgb can normally be allocated from OTC_SELECT as we are processing the
   entire msgb within the select dispatch.  If we end up queueing it somewhere,
   we need to steal it.

b) incoming, forwarded message

   if we already know we'll forward it (e.g. in gb-proxy or bsc_nat), we might
   directly allocate it from OTC_GLOBAL or any of its children.

c) outgoing message

   As we're operating in non-blocking mode, we can never make the assumption
   that any of the outbound sockets will be write-able.  Hence, we always have
   a transmit queue, and as a result we have to allocate from OTC_GLOBAL or
   one of its children.

d) local primitives (osmo_prim)

   As osmo_prim are msgb-wrapped, and primitives [at least for now] are always
   only between our local SAP user and provider (or vice versa) we might use
   OTC_SELECT here, and make sure that all users that want to recycle a osmo_prim
   msgb will steal it, if needed (I don't think that's a very valid use case).

   This applies both ways: for primitives from the provider to the user,
   as well as the other way around.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list