[Asterisk-Dev] Re: is this a bug?

Andrew Kohlsmith akohlsmith-asterisk at benshaw.com
Wed Jan 26 10:52:15 MST 2005


On January 26, 2005 11:59 am, Tilghman Lesher wrote:
> And how many CLIs do you know that start up threads, process jobs, and
> exit, without any direction from the keyboard at the CLI?  There's no
> reaching here:  Asterisk is obviously not a common daemon OR cli
> program, so comparisons to programs which are exclusively daemons or cli
> programs obviously don't hold much water.  Arguably, Asterisk is

My point exactly.  :-)  How many CLIs do you know that will exit on a ^C?  The 
line grows fuzzy.  editors clearly don't, more and less does, midnight 
commander doesn't, asterisk does, pine/mutt/elm doesn't, Perl's CPAN shell 
does, micq doesn't, irssi/bitchx doesn't...

I would go as far as to say that anything where user interaction is common 
traps ^C and either ignores it or displays something along the line of 
"that's not a nice way to exit" -- see below.

> The multithreaded model changes the paradigm quite a bit from the old
> paradigms of forking daemons or single-threaded CLI programs.

Yes and (this is strictly opinion here) in that case it is "odd" that a 
multithreaded app would completely shutdown/die on ^C.

> If you look at asterisk.c, you will see that that behavior is completely
> intentional, by the fact that there is a signal handler for SIGINT which
> calls __quit_handler().  Are you arguing that code that intentionally
> catches the signal and starts the quit handler is a bug?

I didn't call that a bug, I called whatever caused the segfault the OP had a 
bug.

> That's a question for Mark.  Obviously, the current behavior is
> completely intentional, so changing it would change traditional (and
> expected) behavior.

Exactly.  I'm dropping this thread now and adding it to my list of things to 
bug Mark about once I have patches for them.  :-)

-A.



More information about the asterisk-dev mailing list