Luigi Rizzo wrote:
On Thu, Feb 23, 2006 at 01:05:41PM -0600, Dr. Rich Murphey wrote:
...
If you see mpg123 consume 100% CPU upon
shutting down asterisk, this sounds like a
familiar symptom.
I recall looking at mpg123 and finding that
when asterisk exits and closes the pipe to
mpg123, mpg123 would not detect
that the pipe closed, but rather loop indefinitely
reading 0 bytes from the closed pipe.
Since it's possible for the pipe to close unexpectedly
I assumed that this was a bug in mpg123.
this is one part, but there was more to this.
At least on freebsd 4.11 (with libc_r)
there is also a problem when asterisk forks an
external processes and then exec()s a new one, because of
the way the low-numbered io descriptor are handled
(libc_r wants them non-blocking, but since they are shared,
the other program could change them into blocking mode,
which screws up the userland threading library).
The description i posted at the time is here
http://archives.vault9.net/arc/mailing/freebsd-hackers/0218.html
cheers
luigi
Thanks! That explains why it's not necessarily
an mpg123 issue.
Still, mpg123 isn't looking at the error code
returned in the loop where the spin occurs.
Even though the patch doesn't solve the real
issue, it should eliminate the 100% cpu symptom
for mpg123:
asterisk forks in order to exec mpg123,
and when asterisk exits, FreeBSD's libc_r
incorrectly sets mpg123's descriptors
to non-blocking mode, causing it to spin.
Do you have any pointers to the patch that
was rejected because it interfered on linux?
It's a little surprising that mpg123 is the only
issue that has surfaced. It can't be the
only app that uses blocking IO when talking
to asterisk.
Thanks!
Rich
_______________________________________________
Asterisk-BSD mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-bsd
