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)? 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. > 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... > Are there any other special values? I didn't write the code, but I'm quite sure that the answer is no. > Have I misunderstood something? Or is it a bug in pa? Or some > unfortunate artificats for which documentation patches would be appreciated? My personal opinion is that if you have to ask on the mailing list, then most likely there's a problem in the documentation. Documentation patches are very welcome! > Do the same apply to pa_stream_writable_size? Yes. -- Tanu Kaskinen
