[asterisk-dev] (mis)use of threadstorage.h ?

Luigi Rizzo rizzo at icir.org
Sat Nov 25 08:18:10 MST 2006


could someone explain how the code in threadstorage.h is used
and what is it supposed to do ?

I am not sure i follow the code too well because it is hidden
behind several macros, nor i could find in the code any comment
on what this code is supposed to provide.

Browsing through the asterisk source code (details below), i see that
there are the following usages:

1. frame.c and iax2-parser.c, seems the only reasonable usage -
   provide a per-thread freelist of frames. But then i wonder why
   it is not used also in ast_frame_header_new(). (I am also unsure
   why the code in frame.c is replicated in iax2-parser.c)

2. in some cases to make certain routines thread-safe
   (but still not reentrant). As you can see below, in many of these
   cases this is more expensive than it should be; and the fact
   that the code is not reentrant is almost as dangerous as not
   having it thread-safe:

    utils.c
	thread-safe version of ast_inet_ntoa.

    chan_skinny.c::device2str_threadbuf
	local buffer for device2str
	but it would be cheaper to use an automatic buffer in
	the caller (skinny_show_devices())

    chan_skinny.c::control2str_threadbuf
	local buffer for control2str
	but it would be cheaper to use an automatic buffer in
	the caller (skinny_indicate())

    channel.c
	buffer to make ast_state2str thread-safe (but not reentrant)


3. in the remaining cases, i think threadstorage is used in the wrong way,
   as it just allocates a variable whose scope is limited to a single
   function. Here, a plain automatic variable, or an alloca(), would
   suffice, and would avoid the overhead of the ast_alloc()
   (which has locking, and is used anyways for the first allocation
   of these objects):

    chan_sip.c::ts_temp_pvt
	this can just be replaced by an alloca()

    cli.c
	just an alloca() here ? the scope is only local to the function
	ast_cli

    logger.c
	verbose_buf, alloca() ?
	log_buf, alloca() ?

Anything wrong in the above analysis ?

	cheers
	luigi


More information about the asterisk-dev mailing list