From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takashi Iwai <tiwai@suse.de>
Subject: Re: snd_pcsp locking mess
Date: Tue, 21 Oct 2008 09:16:43 +0200
Message-ID: <s5htzb68lk4.wl%tiwai@suse.de>
References: <20080518172258.D0DFB108060@picon.linux-foundation.org>
	<4830737B.70108@aknet.ru> <s5hve1ac05g.wl%tiwai@suse.de>
	<4831B260.1060802@aknet.ru> <s5hhccrx2ey.wl%tiwai@suse.de>
	<4835D774.3070306@aknet.ru> <s5hprrduwdk.wl%tiwai@suse.de>
	<483C10E7.7070203@aknet.ru> <s5h4p8jbvaj.wl%tiwai@suse.de>
	<48AD21EF.8010906@aknet.ru> <s5hej4ibuus.wl%tiwai@suse.de>
	<48AD42A0.9030509@aknet.ru> <s5hzlkz4dsl.wl%tiwai@suse.de>
	<48FCFD7D.6000001@aknet.ru> <s5h4p36a2f7.wl%tiwai@suse.de>
	<48FD7FE1.8000909@aknet.ru>
Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
	by alsa0.perex.cz (Postfix) with ESMTP id 33BFF2473C
	for <alsa-devel@alsa-project.org>;
	Tue, 21 Oct 2008 09:17:01 +0200 (CEST)
In-Reply-To: <48FD7FE1.8000909@aknet.ru>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org
To: Stas Sergeev <stsp@aknet.ru>
Cc: ALSA devel <alsa-devel@alsa-project.org>
List-Id: alsa-devel@alsa-project.org

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