[asterisk-dev] Channel lock in "core show channel" CLI command ?

[Pavel Troller]

> On 09/15/2011 12:02 AM, Pavel Troller wrote:
>> Hi!
>>    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 :-)
>
Hi Kevin,
  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.

With regards,
   Pavel Troller