Bug#465474: asterisk: Please add thread-safe channel locking alternative

[Philipp Berndt]

Package: asterisk
Version: 1:1.2.13~dfsg-2etch2
Severity: wishlist
Tags: patch

In some occasions ast_mutex_lock(&chan->lock) is used where chan could
already have been freed. This is of course not thread-safe.

In this case the only thread-safe way to atomically check for and lock a
channel would be to use channel_find_locked(). However this method has three
disadvantages in the described context:

- It is somewhat slow because it needs to do string comparison.
- You need some other information (besides the channel pointer) by which to
  search.
- By trying to lock 10 times the semantics of channel_find_lock is something
  like a compromise between lock and trylock.
  (This is not what you want because if you can't lock chan->lock you
  will probably want to release locks on mutexes outside of
  channel_find_locked(), too before you try again.)

See patch for suggested solution.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages asterisk depends on:
ii  adduser            3.102                 Add and remove users and groups
ii  asterisk-bristuff  1:1.2.13~dfsg-2etch2  Open Source Private Branch Exchang

asterisk recommends no packages.

-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast_channel_trylock_safe.dpatch
Type: application/x-shellscript
Size: 2424 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20080212/fe7acb32/attachment.bin