Re: snd_pcsp locking mess

[Takashi Iwai <tiwai@suse.de>]

At Tue, 21 Oct 2008 11:08:17 +0400,
Stas Sergeev wrote:
> 
> Hi.
> 
> Takashi Iwai wrote:
> > The PCM status is changed immediately after calling trigger(async)
> > callback XRUN or SETUP.  That is, you can start the stream again soon
> > after snd_pcm_stop().  In the case of async operation, the hardware
> > may be likely still running, but the PCM core doesn't know about it
> > and allows you to restart the stream.  So it's racy, at least from the
> > PCM core viewpoint.
> OK but how does _my patch_ affects this?

No, your patch does essentially NOTHING by itself.
However...

> Before, the trigger() callback was called
> both synchronously and asynchronously. My
> patch only provides the callback to make
> it possible to separate the sync and async
> parts. It doesn't do anything more. It
> doesn't change anything at all. So how
> could exactly that patch introduce the race
> you mentioned? There was already an async
> invocation of trigger() callback. I wanted
> to add just a callback under different name
> for that. What could my patch possibly
> change? How does it _introduce_ the race?

Because the async trigger itself can be racy easily, there is no merit
to add a common callback until we have a proper handling of delayed
triggers in the PCM core side.


Takashi