Paul Davis wrote: > > >I'm not speaking about programming bugs. Suppose the PCM is stopped by > >another thread: you're screwed. > > why are you screwed? you're waiting (presumably) for data/space to be > ready in the PCM device. there isn't any (or more precisely, you're > waiting for changes in the state of data/space, and there are none). i > don't see the problem.
The thread has no way to detect what's the cause of data/space lack without busy loop or delaying. > >> > As pointed by Clemens the current is the proper POSIX behaviour. > >> > > > >Perhaps you should reread Single Unix Specification, I quote > >http://www.opengroup.org/onlinepubs/007904975/functions/poll.html > > > >POLLIN > > Data other than high-priority data may be read without > >blocking. > > > > > >POLLOUT > > Normal data may be written without blocking. > > > > > >No data may be read/written in current stream state in the case we are > >discussing. > > but nobody has suggested that poll(2) should return any flags with > these bits set. the issue, i thought, was what should write(2) do ... No, the issue was about poll and write. The point is that stream is in bad state wrt read/write, this is the reason why poll should return POLLERR. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ------------------------------------------------------- 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