On Tuesday 17 September 2002 16.40, Clemens Ladisch wrote: > > I feel that one can interpret both ways, so it is a quite open > > choice. Either way, one can state POSIX behaviour. Then the > > question becomes: what is the most usable behaviour? > > I think we have only two choices for POSIX-compliant write() > behaviour in the prepared state: > > 1) Don't allow any writes. Always return EPIPE. > (my interpretation above) > > 2) Allow writes until the buffer is full, then block. > (Takashi's second interpretation) > > The current ALSA implementation is an inconsistent mixture of both: > returning EPIPE means that it is impossible to write, but then it > should not have been possible for the first bufferfull to succeed. > > And we want to be able to fill the first buffer, so IMHO 2) is the > way to go.
So, are we going to see a change in behaviour here? It seems like everyone which has discussed this, except Abramo, wants to see a change to the second interpretation which is: * write() blocks on blocking mode when output buffer is full, and returns EAGAIN when in non-blocking mode. * poll/select blocks when output buffer is full ...with no difference if the card is running or not. Today, it is a different behaviour when the card is not running, where write returns EPIPE (both blocking/non-blocking) and poll/select does not block. The arguments for keeping the current behaviour is according to its supporter(s?): * It is easier to detect bugs which else would dead-lock the program * It is more logical, like a pipe with the hardware in the read end The arguments for changing to the new are: * It is sometimes used in multi-threaded programs (fill buffer in one thread, start from another). * The current behaviour has no use apart from detection of a trivial dead-lock bug. * Especially in multi-threaded programs, the current behaviour with EPIPE can be confused with underruns or overflows, making the "easier-to-detect-bug" feature to have the opposite effect. * It is a POSIX-compliant behaviour which the current is not * It is more logical, always same behaviour, no special case for cards not running * It seems to be the more popular choice, and would break very little if any if implemented. Ok, I said I would stop argue about this, so sue me. /Anders Torger ------------------------------------------------------- This SF.NET email is 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
