[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