Anders Torger wrote: > > On Monday 16 September 2002 21.31, you 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. To a beginner which has never seen a unix system before, > this might be the case. For anyone that has programmed with file > descriptors before, this behaviour appears broken, and is therefore > harder to understand. > > 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. > > * It behaves as programmers expect it to behave > * It simplifies multi-threaded programming
Please use technical argumentations: pseudo statistical and subjective ones does not worth a lot. > "If the sound card output buffer is full of data, and it is not > running, what would happen if you poll that file descriptor for writing" > > 1) it will block, because it is not ready for writing > 2) it would not block, because it would then block forever 2 is better because the programmer can know the reason of failure. With 1 the programmer will not receive enough info to detect it (also using a timeout) > "If you write to a non-blocking sound card output file descriptor, but > the buffer is full, and the sound card is not running, what will then > happen?" > > 1) it will return with errno set to EAGAIN, because it is not ready for > writing > 2) it will return with errno set to EPIPE, because there is a buffer > overflow 2 is better because EAGAIN would be returned also if buffer is *temporarily* full. Consider also that "retry again later" is definitely a misleading hint. > In conclusion, I advice you to change the behaviour to what we as > programmers expect, and sometimes program for. I would very much > appriciate it, and I'm sure others will as well Please understand that it's very hard to satisfy everybody and I'm not sure it's a worthy goal. That apart, I'm very interested to hear further technical reason to change current behaviour. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ------------------------------------------------------- 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
