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

[Paul Fox]

jon wrote:
 > 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?

yes, completely, for me.  i'd be interested if it fixes david woodfall's
problem as well.  (cc'ed, in case he's not on the mailing list.)

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

that's my guess too.  i'm running nasd on top of libaoss, which sits
on top of alsa's libasound.  i do this rather than use the alsa OSS
compatibility devices because those don't let me mix nasd output with
the output from regular alsa clients.

be sure and look at the stack backtrace i sent earlier.  once you look
at the code, and the trace, it's fairly clear (i think) what must be
happening.

paul
----------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 76.1 degrees)