On Fri, 11.12.09 03:27, Tanu Kaskinen (tanuk at iki.fi) wrote: > > to, 2009-12-10 kello 21:20 +0100, Mads Kiilerich kirjoitti: > > With reference to > > http://0pointer.de/lennart/projects/pulseaudio/doxygen/stream_8h.html#aa2e5ff19aa36b90471c34badbdfdf345 > > and using pulseaudio-0.9.15-17.fc11.i586: > > > > My experiments shows that pa_stream_readable_size() sometimes returns > > 4294967295 = 0xffffffff. That possibility is not described in the > > documentation, AFAICS. > > > > However, I have only seen that happen when not PA_STREAM_READY. Is the > > ready state a precondition for calling this function? How should race > > conditions be avoided? > > Yes, the READY state is a precondition. > > What kind of race conditions do you mean? Do you mean that how are you > supposed to know prior to calling pa_stream_readable_size() whether the > stream is still in READY state? Are you not able to reliably track the > state with a state change callback (pa_set_state_callback)? Also, you can just call _readable_size(), and then check if that failed. Duplicating the state check externally is not necessary. > I'm not terribly familiar with the client library details, so I'm not > saying that there are no races. But since the library is > single-threaded, I believe you can use the state callback to always have > the same knowledge of the state as the library itself. That is true. The PA libraries are not generally thread-safe, however they are threads-aware. > > It would have matched my expectations better if the type was ssize_t and > > the value thus -1. > > Pulseaudio uses ((size_t) -1) in error cases in many places. I guess > it's at least partially a matter of taste... Yes, that is true. > > Are there any other special values? > > I didn't write the code, but I'm quite sure that the answer is no. Yes, that is correct. The answer is "no". Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
