[Asterisk-bsd] Real usefullness of mpg123 dependency / rxfax note

[Dr. Rich Murphey]

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