From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Why do I get broken pipe on write to a pcm in statePREPARED? Date: Tue, 17 Sep 2002 13:09:36 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200209162014.g8GKEc014124@d1o87.telia.com> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Clemens Ladisch Cc: Anders Torger , Abramo Bagnara , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Tue, 17 Sep 2002 11:05:44 +0200 (METDST), Clemens Ladisch wrote: > > Anders Torger wrote: > > On Monday 16 September 2002 21.31, you [Abramo Bagnara] wrote: > > > I think that the best behaviour is the current and it's also the > > > simplest to describe and to understand: poll/select never blocks when > > > there is nothing to wait. > > > > > > ... and in PREPARED state definitely there's nothing to wait from > > > sound card. > > > > I don't agree. (...) > > > > Also, as we have noted, there is no real use for the current behaviour > > (at least no-one has said what it is), while there is use for the > > proper work-as-all-other-file-descriptors behaviour. > > IMHO the current behaviour is the proper behaviour as implemented by other > file descriptors, and as mandated by POSIX. good point. referring to POSIX helps our decision. > > says regarding pipes, FIFOs and sockets: > | The write() function shall fail if: > | (...) > | [EPIPE] > | An attempt is made to write to a pipe or FIFO that is not open for > | reading by any process, or that only has one end open. > | (...) > | A write was attempted on a socket that is shut down for writing, or is > | no longer connected. > > > > It makes sense to block, there may be another thread, or even another > > process starting the sound card. > > In the cases cited above, there may be another thread/process which will > open the other end of the FIFO, or connect to the socket. But write() only > looks at the state of the file descriptor at the time the call is made, > and does not take into regard what _might_ happen in the future. > > The 'prepared' state is equivalent to the EPIPE cases above because it's a > state in which the pcm device is _not_ reading data. but are you sure that this feature is really implemented? on my system, write() to an FIFO which is not opened for read doesn't fail, for example, % mkfifo /tmp/foo % cat /dev/random > /tmp/foo and cat is blocked, not failed. i'll check how poll() behaves... Takashi ------------------------------------------------------- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab