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. > <http://www.opengroup.org/onlinepubs/007904975/functions/write.html> > 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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
