On Monday 07 October 2002 14.07, you wrote: > Takashi Iwai wrote: > > it CAN happen if you have multi-threads. > > the problem is that we have no option to block the poll. > > If you have multi-thread you have other alternative to do that. > OTOH application can't detect *why* poll is blocking with the change > you advocate.
This is a non-issue. I think it is larger risk to search for the wrong problem (like I did), that is beleiving that there is a buffer underrun or similar. This type of blocking bug is very easy to detect and debug, I don't think the bug-detection argument is important, and that is also the only argument for the current behaviour (apart from that it is bad to change APIs). > > > That apart I'm sure that to make a change in actual behaviour > > > between rcX and 1.0 is a professional suicide. However it's > > > _your_ professional suicide so... ;-))) > > > > yes, i know it well ;) > > > > i don't like to change this inevitably, too. > > and as mentioned above, i don't mind to add an option as sw_params, > > etc. for the new behavior. > > > > but the current behavior is incorrect from the interpretation of > > POSIX. so this must be a bug. > > if we have to change it, then i would choose the new one, because > > it's more intuitive without exception. > > As pointed by Clemens the current is the proper POSIX behaviour. Perhaps you missed it, but he actually changed his mind, I have cited below. ----------------- 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. Regards, Clemens ----------------------------- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
