[nas] (resend) hard hang in libaoss.so

[Jon Trulson]

On Thu, 4 Jul 2013, Erik Auerswald wrote:

> Hi,
>
> On Thu, Jul 04, 2013 at 08:44:49AM -0400, Paul Fox wrote:
>> erik wrote:
>> > On Wed, Jul 03, 2013 at 04:09:30PM -0400, Paul Fox wrote:
>> >> i believe the problem is that if we take an alarm signal while still
>> >> in the middle of disableProcessFlow(), we'll call disableProcessFlow()
>> >> again.  so rather than clearing the processFlowEnabled flag when we're
>> >> finished disabling, we should probably clear it beforehand, as in this
>> >> patch.
>> >
>> > The idea sounds right, and on Linux (or rather not on SCO) it should reduce
>> > the race window significantly.
>>
>> do you see obvious further window(s)?
>
> I didn't, but I'd like Jon to comment on this. He is much more familiar
> with the code than I am.
>

Yeah, I'll need a little time to look it over - I remember this code
being a little tricky.  Does your fix actually solve the problem?

I'm guessing that on your system SNDCTL_DSP_SYNC takes some time,
thereby opening up the potential for a race.

>> > Does the following patch work as well?
>>
>> i'm sure it would.  but i was actually going to suggest a different,
>> second patch.  i was going to suggest removing the sco ifdefs entirely.
>>
>> thoughts?
>
> IMHO the sco #ifdefs should be removed. They complicate reading the code,
> encumbering maintenance (as in this case).
>
> I still think we should first address the issue at hand (reducing the race
> window), perhaps even making a maintenance release with this fix.
>

Agreed.  Also, I have no problem removing the sco stuff (in a seperate
future patch) either.

> Afterwards we should remove the sco #ifdefs in one go from the
> voxware server.
>
> If someone wants to help maintain SCO compatibility, feel free to speak up.
> :-)
>

Yep :)


-- 
Jon Trulson

   "I was not genomed to alter reality."
       - Sonmi 451