[alsa-devel] snd_pcsp locking mess
tiwai at suse.de
Tue Oct 21 09:16:43 CEST 2008
At Tue, 21 Oct 2008 11:08:17 +0400,
Stas Sergeev wrote:
> 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.
> 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.
More information about the Alsa-devel