[asterisk-dev] Channel lock in "core show channel" CLI command ?
patrol at sinus.cz
Thu Sep 15 07:44:22 CDT 2011
> On 09/15/2011 12:02 AM, Pavel Troller wrote:
>> I've found that executing the "core show channel" from the primary Asterisk
>> console (the one which it spawns upon startup) causes the channel audio to be
>> muted during the command execution. I think it's a locking issue: the command
>> is executed in the locked state of the channel. However, on a primary console,
>> execution of this command can take about 2 seconds, especially on a system
>> with framebuffer consoles (no X) and thus slow scrolling, and when there are
>> many channel variables. Because ast_cli function seems to run synchronously,
>> i.e. blocking until the text is really output, for all this time the channel is
>> dead. Using remote console (asterisk -r even on the local host) doesn't make
>> problems, probably because ast_cli runs asynchronously in this case and the
>> text is buffered on the remote console.
>> Would it be possible to use something like a sprintf() function to prepare
>> the command output to an extra buffer, unlock the channel and then call the
>> ast_cli with the buffer instead of live data ? I don't see a major problem
>> there. If you agree, I could try to write a small patch for it.
>> With regards,
>> Pavel Troller
>> P.S. It's on 1.8 branch, maybe the problem is already fixed in trunk ?
> No, I don't think any attempt has been made to address this; however, as
> you say, the problem is not really in Asterisk, it's caused by the console
> being incredibly slow. The solution, of course, is to not configure your
> system in a way that causes the console to be so slow :-)
thanks for your valuable opinion, but today it's very hard to find a system
with fast text consoles. Current video cards (including the on-board ones on the
"productivity" mainboards) obviously cannot setup other SVGA text modes than
80x25 or 80x50. Formerly, there were modes like 132x43, which were usable for
a Linux console, but 80x25 is a real pain. The only choice in such a case is
a VESA framebuffer, which tends to be slow.
However, as an operator of "real exchanges" (EWSD, DMS100, CS2K...) I've
never seen that a terminal slowness would affect call processing (and these
exchanges used to output to mechanical teletypers or similar slow devices).
I think that this is bad design: for example, I can accidentally press Ctrl-S
or Scroll Lock key in the middle of the printout and the channel will be
blocked permanently. I still think that making the output operation
asynchronous would make sense and I will try to patch it, at least for 1.8.
More information about the asterisk-dev